I think there's a tension between the types of belief that drive product decisions - on one hand, you have people driven by the belief that they understand what the customer wants, via copious amounts of research and interviews, and they happily create a bundle of features and label it as the MVP, and follow the path you've laid above.
On the other hand, you have some product directors driven by belief in themselves that they know what they would want, as users of the product, and they want to show the future users the real way to do X.
It's a bit like a marvel film vs. a film by a director with a point of view. For the marvel films, they've focus group'd and researched everything to the Nth degree, and so they've settled on something that they know will work for an audience in a specific way, but will never innovate, and, eventually, can become stale.
On the other side, a director driven by belief will make movies that can definitely approach something greater than a marvel film - they can deliver something great that you don't expect, something you may not have even know you wanted, but something that the team behind the film wanted you to have.
In product world, I'd look at instagram + snapchat as those two roles - instagram was bought and then maintained eventually as facebook-but-only-photos. Snapchat was constantly innovating and instagram could only copy what they were doing - filter, geolocations, etc. Sadly being first and best doesn't always translate into victory for software products, but there are worse things to say at the end of a project than, "we forced our biggest competitor to copy everything we've made because they recognize it is so good".
I think the main sticking point for me when working on a new product and trying to innovate is the constraints of the SaaS space. In SaaS, enterprise is often not looking for innovation explicitly (unless they've heard about it, like in the case of AI). The buyers are typically looking to fill a checklist of features. So you get forced into death-spiral-by-necessity, and then, at the end, wonder why your MVP isn't cutting it despite checking all the boxes.
Shared this with a friend earlier, seems relevant here too:
It's "natural" to think supply-side. It's "natural" to gravitate towards listing stuff (you want) to do. Most designers, coders, builder-types are much more comfortable in the supply side. They got into the game because they love cool stuff. They want to do something polished because they have taste and not-polished stuff isn't cool. Non-polished stuff isn't legitimate, and wouldn't put them in the club of cool makers.
It's good to build something cool for its own sake. It's good to build something just to have built and shipped it.
It's good to spot demand in the market and start meeting that demand. It's good to help people make progress.
The killer is when you mix up the two: when you think you can solve a demand-side challenge by doing more supply-side stuff, or vice-versa.
There are good negotiations between demand-side and supply-side.
But MVP is a bad negotiation.
MVP is simultaneously the least efficient way to find demand AND the most efficient way to kill your joy.
It's an attempted deal with the devil. "If we give up the joy of making this thing, please will you make it so the market wants it?" ... and the devil is just laughing at you.
But you probably can't tell people this and have them 'get it'. There will always be beans and noses.
Here's an exercise you can try though:
1) Have the person in charge complete the story: "when we've shipped [Product X], it will help [Person A] with [Struggle B]" (pick a person and a struggle. If there are lots of possibilities, write them all down and then pick the one you think is most valuable.)
2) Write out two statements:
A) We just want to help Person A with Struggle B – even if that means we never build Product X
B) We just want to build Product X – even if that means we never help Person A with Struggle B
3) Have them pick one. There's no right answer. Both are valid, both are cool, both can work (in different ways). But you do have to choose.
> Stop trying to pick the right features to make your product awesome. Start trying to enable the right behaviours to make your customer awesome.
I’m always struggling to make this exact argument.
Great article as always!
Thanks!
And keep fightin' the good fight! How might you characterise the struggle? What does it feel like for you?
I think there's a tension between the types of belief that drive product decisions - on one hand, you have people driven by the belief that they understand what the customer wants, via copious amounts of research and interviews, and they happily create a bundle of features and label it as the MVP, and follow the path you've laid above.
On the other hand, you have some product directors driven by belief in themselves that they know what they would want, as users of the product, and they want to show the future users the real way to do X.
It's a bit like a marvel film vs. a film by a director with a point of view. For the marvel films, they've focus group'd and researched everything to the Nth degree, and so they've settled on something that they know will work for an audience in a specific way, but will never innovate, and, eventually, can become stale.
On the other side, a director driven by belief will make movies that can definitely approach something greater than a marvel film - they can deliver something great that you don't expect, something you may not have even know you wanted, but something that the team behind the film wanted you to have.
In product world, I'd look at instagram + snapchat as those two roles - instagram was bought and then maintained eventually as facebook-but-only-photos. Snapchat was constantly innovating and instagram could only copy what they were doing - filter, geolocations, etc. Sadly being first and best doesn't always translate into victory for software products, but there are worse things to say at the end of a project than, "we forced our biggest competitor to copy everything we've made because they recognize it is so good".
I think the main sticking point for me when working on a new product and trying to innovate is the constraints of the SaaS space. In SaaS, enterprise is often not looking for innovation explicitly (unless they've heard about it, like in the case of AI). The buyers are typically looking to fill a checklist of features. So you get forced into death-spiral-by-necessity, and then, at the end, wonder why your MVP isn't cutting it despite checking all the boxes.
I could go on but I will cut myself off here.
Shared this with a friend earlier, seems relevant here too:
It's "natural" to think supply-side. It's "natural" to gravitate towards listing stuff (you want) to do. Most designers, coders, builder-types are much more comfortable in the supply side. They got into the game because they love cool stuff. They want to do something polished because they have taste and not-polished stuff isn't cool. Non-polished stuff isn't legitimate, and wouldn't put them in the club of cool makers.
It's good to build something cool for its own sake. It's good to build something just to have built and shipped it.
It's good to spot demand in the market and start meeting that demand. It's good to help people make progress.
The killer is when you mix up the two: when you think you can solve a demand-side challenge by doing more supply-side stuff, or vice-versa.
There are good negotiations between demand-side and supply-side.
But MVP is a bad negotiation.
MVP is simultaneously the least efficient way to find demand AND the most efficient way to kill your joy.
It's an attempted deal with the devil. "If we give up the joy of making this thing, please will you make it so the market wants it?" ... and the devil is just laughing at you.
But you probably can't tell people this and have them 'get it'. There will always be beans and noses.
Here's an exercise you can try though:
1) Have the person in charge complete the story: "when we've shipped [Product X], it will help [Person A] with [Struggle B]" (pick a person and a struggle. If there are lots of possibilities, write them all down and then pick the one you think is most valuable.)
2) Write out two statements:
A) We just want to help Person A with Struggle B – even if that means we never build Product X
B) We just want to build Product X – even if that means we never help Person A with Struggle B
3) Have them pick one. There's no right answer. Both are valid, both are cool, both can work (in different ways). But you do have to choose.