I was having a conversation with some colleagues about development of the MVP (Minimum Viable Product) and the related sales cycle. I argued that it’s easier to sell the value of an underlying technology than a product. The following is my explanation as to why that is in many cases.
Most entrepreneurs we encounter these days are technology folks, many are software or systems engineering professionals. They could be students, recent graduates or experienced professionals.
The tendency (me included in my past life) for us was to start building out an idea because we knew how to do it. We would start building, even though we knew that we were taking that leap of faith risk that leads to the idea/ app graveyard.
This is the classic waterfall approach, since we are really taking an idea and then starting to build the MVP, then hoping to get some sort of traction from peers, friends and maybe even some potential customers.
Since this has been covered at length in many resources, I wanted to introduce the concept of blueprinting the idea as a “technology in support of an idea” vs. a product. The variables can be plotted into a matrix and these can be visually mapped against a potential business model using tools like the Business Canvas/ Investment Readiness Level tool.
The other conceptual change to the product build mindset, is to consider the idea as a service first, rather than a product. The reason for this is twofold; first, it’s easier to meet a potential customer’s needs if your service offering is flexible and agile in nature vs. a locked down feature set found in the productized deliverable.
Secondly, it allows the potential customers to give you segmentation feedback that would otherwise come at a great expense- time and rework of the product /market fit.
When it comes to customer development or planning how to sell this early stage framework, you can rest assured that the first round of conversations can be explained just as well with a story based on the idea than with a demo of an MVP. (not always the case, just work with me here)
The risk of developing the MVP first is that you feel you have to try to convince the potential customers that they “have” to accept the idea and product as a symbiotic purchase at the expense of listening to their thoughts and feedback.
As much effort that you might have put into the MVP development (and subsequent feature updates and pivots) should really go into your story boarding about making the emotional ties with potential customer groups. This is the rudimentary market research phase and it should not be overlooked. This is a skill set which needs to be developed.
The main focus is learning how to clearly communicate your value proposition in terms of customer use cases etc. based on your functional models. The need for a demo is usually a distant second in terms of what customers need to see. You can use mock ups, models etc. to aid in your conceptualization. (see main image as an example)
So if you are following along with me here, you could go and assemble the “services framework” based on a couple of methods. Existing tools and platforms which can be quickly assembled and modified- open source code, scripts, agile tools or labs vs. custom coding for the MVP. There are also crowd sourcing methods of getting things built these days.
The second approach would be to work with others who have already proven their technology and partner with them. You could private label, do a Joint venture etc. to get what you need to create a tangible sandbox to deliver your “work in progress”. (if there is a fit obviously. This is something I would always look at before building first)
So in essence, we are learning how to sell the underlying technologies rather than a product. We can approach the conceptual stage with thinking of the product as a service first, to get the best ROI for our time and make a better fit with potential customers. We can also look at alternatives to the perpetual martyrdom of building products from scratch ourselves, just because we have the skills.
Attracting capital is more a function of a well thought out approach which considers the reality of spending others’ capital on product development rather than developing a viable business framework. It’s not as difficult to explain how you will build something when you convince your audience you have answers to all of the value proposition and business model questions, based on feedback from real potential customers.
This should also help many understand that the MVP is not a Release Candidate born of product development, but a base level services matrix of functions as honed down from customer inputs. Make Sense?