An often inconsistently used jargon in product is the “minimum viable product”. Here’s the 2-dimensional framework I use to think about when a product can be called an “mvp”.
1. The “viable” part of the MVP solves for both technical viability (can you build it) as well as market viability (will the right users buy it).
2. The path to MVP thus balances product building activities with market engineering activities.
3. These two complementary motions together run in parallel through many iterations before you reach proof of viability.
On the path to MVP, teams can cross deceptive stages which can mislead into believing you have an MVP . Here’s a couple of pre-mvp variations when product/market engineering activities are out of sync:
🧲 Early testable product – When teams end up over-indexing on product execution and under-index on market engineering. They have solved for technical risk early on but haven’t proven market viability yet. This is debt that needs to be paid off before go to market can pick up velocity.
🎥 Market discovery vehicle – When teams have over indexed on market engineering activities using prototypes / tools or even Wizard-of-ozes to gain some customer validation. But they haven’t proven if the build is feasible within the team’s operating constraints.
Before scaling your go-to-market motions , teams need to make sure they are truly at an MVP stage and have mitigated both risks to some extent. Will prevent a ton of churn, re-work pains and lost capital down the line.
More to follow on what constitutes Market engineering activities as part of the MVP process, who needs to be involved alongside product and what are some good systems to set up.
#productmanagement