The ability to understand and develop an MVP is a crucial skill in almost any company or organization. The Minimum Viable Product is a working product aimed at testing the core assumption(s) behind an idea, a concept or a new service that a venture is aiming to launch. A great deal of effort is especially required to understand what the core assumption of the product actually is, for it is very common (especially for technical people) to start tinkering and coding when a faster and easier solution could have proven the viability of the venture without the need for a single line of code.
Technodytes
In the eyes of marketers, product managers and strategists, tech people are very trigger-happy around solving specific tech problems and not really interested in the bigger picture. As I definitely belong in this group, the best epithet that I’ve heard in describing techno-happy people is Techno-Troglodyte: but since I don’t like composed words, let’s refine it a bit and voilà, we have Technodyte (literally “she-he who dives in tech” ). Nice.
A typical MVP out of a team of Technodytes is usually very unbalanced on the medium for delivering the solution (be it an app, a bot, a drone) rather than on the solution itself. In other words, if we look at the Lean Cycle, not a lot of thought is put into the “Should we do it”.
“Sony seem to be totally focused on technology invention and product innovation, rather than thinking across all three parts of the Lean Startup cycle. They are favoring ‘can we do it’ over ‘will customers want it’ and ‘can we make money out of it’. Considering all three parts together is vital in order to launch successful products rather than mere trinkets.”
On the other hand, it is very common for non-technical people to make specific assumptions and draw conclusions about the technical side of a venture without a clear understanding of the actual requirements and implications. In this case, when finally approaching a dev (or engineering) team they tend to give a set of requirements based on their technical experience and understanding and if the Dev Lead is not proactive enough to challenge the given requirements, the success of the venture could be definitely jeopardized.
Intermezzo: obligatory media rant
The landscape of news media from where tech-curious people tend to gather their information is often polluted by click-baity pieces written by journalists lacking the skills to challenge a company’s marketing-y press release. Recent examples can be found in the buzz and distraction around quantum computing, artificial intelligence, delivery drones, robo-taxes and the lot.
Agencies and Boutiques
When a company lacks internal skills to build an MVP, agencies and boutiques tend to see more value in Waterfall solutions (aimed at building a final — yet unproven — product) than in Agile since the latter could be killed after almost every sprint. This is a crucial point for agencies, consultants and boutiques: the adoption of LEAN and Agile should not be seen as a threat to their revenue (just at their fixed-fee business model).
At what stage should we build the MVP?
It is easy for both technical and non-technical people to overestimate or underestimate a product’s requirements. This is of course not to say that tech-savy managers, marketers or consultants shouldn’t have a say on the requirements, but that there is the need of a figure with a little bit of both backgrounds to understand the bigger picture and manage expectations with an eye for technical feasibility.
Even in a LEAN environment, it’s vital to have a clear-enough understanding of several points, following the “Playing to win” methodology, at the MVP stage we should have already cleared the following:
1. What is our winning aspiration?2. Where will we play?3. How will we win?4. What capabilities must we have?5. What management systems do we need?
— Alan G. Lafley and Roger Martin, Playing to Win: How Strategy Really Works (Harvard Business Review Press, 2013)
Also, the line between a POC (proof of concept) and an MVP can be blurred. For some the POC comes after the MVP and is a way to test the value proposition by gathering real-world usage metrics that shows traction with customers. For some it’s the opposite, and the difference is:
Proofs of Concept validate “something people need” can be built. Minimum Viable Products validate that “something people need” should be built. Customers don’t see the POC’s. That kind of thing is done in-house. They do see the MVPs and that is what they are willing to buy. Remember this: POC’s test feature validity, MVP’s test market viability.
— Jason Thomas, Proof Of Concept Vs. Minimum Viable Product (And When To Use Each)
I tend to follow Jason’s distinction. Another great resource to understand why an MVP is required in the first place is the mighty steve blank:
A minimum viable product (MVP) is not always a smaller/cheaper version of your final product.[…] The team confused the goal of the MVP with the process of getting to the goal.
— Steve Blank, An MVP is not a cheaper product, it’s about smart learning
An example: the shoe-ticket
Let’s assume that, following the strategy defined by a public transportation provider we now have the following user story: “As a tube commuter I want to quickly catch the train so that I can arrive on time at my destination”. In order to speed up the journey there are several areas of focus, but let’s assume that our team is exploring different ways to optimize the ticket barriers. Here’s a couple of ideas:
- We could augment the speed at which the barriers open
- We could augment the speed at which the tickets are read (e.g. by using contactless)
- If it’s proven to be faster, we could eliminate tickets and use biometrics (e.g. fingerprint readers)
- If it’s proven to be faster, we could eliminate the barriers and use image-recognition to bill the customer
- We could propose a ticket that sticks to the bottom of a shoe and is read by a contactless reader on the floor
- We could eliminate the need of payment by envisioning a public tax to support transportation, etc…
Granted, some solutions are rather extreme: but let’s say that the shoe-ticket looks promising and that the business wants to test it.
The POC
Since the contactless technology is quite proven, we may be tempted to buy two off-the-shelf components like an RFI tag and an RFI reader and stick it under a shoe to test the concept. However, I would suggest that we should instead focus the efforts on the glue and the shape of the RFID tag since it’ll need to withstand enormous stress. In this case, a POC could be a combination of material and glue that can fit on almost any shoe in any condition (what happens when the tag is wet? what happens when there’s mud? what happens when the person is running?).
The proof of concept proves that the solution is viable and the technology exists.
The MVP
The MVP will therefore look like a metal stripe or panel able to read RFIDs (possibly a repurposed off-the-shelf device) and a set of tags to be given to the customers. The MVP will then gather data and assess, through insights about its usage, whether or not customers prefers that solution over the normal ticket barrier.
At any point, we will be able to kill the venture based on evidence of usage or of unforeseen problems (like high heels or tennis shoes).
Right. Granted, our venture is likely to fail. However, thanks to our MVP we will have failed fast and cheap and we’ll still have resources to explore another, better solution.
