Lenny's podcast had an interview with Eric Ries not long ago. They discussed one of the common challenges: what exactly is minimal. Ofc. "It depends" and it gets more difficult depending on stakeholders. But what I really took away is to break that "what is minimal enough" cycle, you just go with the smallest. If you don't know what minimal is in your case, do the "minimallest", and learn from that. Saved me from a number of endlessly circling talks.
Sparked by Ries saying: "the problem with most MVPs is you often don't really know what minimal, viable and the exact product is up front. Best to start smaller then. (paraphrasing)
Do you have an alternative name/acronym for the sort of misused MVP that is the startup's first "minimal" public-to-users "prototype" that seems so common?
I was referring to your "temptation in StartupLand" where they say "MVP" but really mean releasing an early working prototype to (a subset of) users....
But how do you manage user expectations in this flavor of MVP? If you are upfront that the product is designed to answer *your* question and die quickly, what incentive do they have to engage and help you?
Furthermore, even if they do engage, how would you know if their behavior is representative or they are just kicking the tires?
Keep the initial cohort of users small & enthused. There are people who just want to be trying the new new. They are excited by novelty & tend to be forgiving if you feed that excitement. Get feedback from them, engage intensely, then when you find something they are recommending to their non-enthusiast friends, that's when you know you have something.
This makes the approach conditional on having/being able to create such user base. Perhaps we need a different name for delivering through small increments that bring value to the end customer.
Also, is it one or the other, or could there be a spectrum between cheaply answering a question for the developer vs. cheaply satisfying a need for the end customer?
There's a huge difference between finding a source of value & delivering on that value (see all my 3X: Explore/Expand/Extract material for more details). The intent of MVP is finding a source of value. Small increments that bring value to a known end customer in a known way is, I agree, a completely different activity, even though they both look like software development.
I agree. I still use use the term MVP because it's so common, but I explain LOUDLY it's purpose of learning quickly rather than making sales. I've also seen others like MDP, MMR, MMP, MLP but they seem to confuse more than anything. I think a related issue is when companies unknowing build a prototype (in pursuit of speed) believing it's an MVP, which then gets built on and used in the wild when it falls apart.
Lenny's podcast had an interview with Eric Ries not long ago. They discussed one of the common challenges: what exactly is minimal. Ofc. "It depends" and it gets more difficult depending on stakeholders. But what I really took away is to break that "what is minimal enough" cycle, you just go with the smallest. If you don't know what minimal is in your case, do the "minimallest", and learn from that. Saved me from a number of endlessly circling talks.
Sparked by Ries saying: "the problem with most MVPs is you often don't really know what minimal, viable and the exact product is up front. Best to start smaller then. (paraphrasing)
Do you have an alternative name/acronym for the sort of misused MVP that is the startup's first "minimal" public-to-users "prototype" that seems so common?
I don't understand what you mean by '"minimal" public-to-users "prototype"'. Do companies release too soon or too late, in general?
I was referring to your "temptation in StartupLand" where they say "MVP" but really mean releasing an early working prototype to (a subset of) users....
But how do you manage user expectations in this flavor of MVP? If you are upfront that the product is designed to answer *your* question and die quickly, what incentive do they have to engage and help you?
Furthermore, even if they do engage, how would you know if their behavior is representative or they are just kicking the tires?
Keep the initial cohort of users small & enthused. There are people who just want to be trying the new new. They are excited by novelty & tend to be forgiving if you feed that excitement. Get feedback from them, engage intensely, then when you find something they are recommending to their non-enthusiast friends, that's when you know you have something.
This makes the approach conditional on having/being able to create such user base. Perhaps we need a different name for delivering through small increments that bring value to the end customer.
Also, is it one or the other, or could there be a spectrum between cheaply answering a question for the developer vs. cheaply satisfying a need for the end customer?
There's a huge difference between finding a source of value & delivering on that value (see all my 3X: Explore/Expand/Extract material for more details). The intent of MVP is finding a source of value. Small increments that bring value to a known end customer in a known way is, I agree, a completely different activity, even though they both look like software development.
I agree. I still use use the term MVP because it's so common, but I explain LOUDLY it's purpose of learning quickly rather than making sales. I've also seen others like MDP, MMR, MMP, MLP but they seem to confuse more than anything. I think a related issue is when companies unknowing build a prototype (in pursuit of speed) believing it's an MVP, which then gets built on and used in the wild when it falls apart.