SpaceX’s goal is “settle Mars”, its MVP was “build a low-earth orbit launch system”, and sub-MVPs of that (experiments to validate the highest-uncertainty thing they needed to validate) consisted of things like engine test firings.
Using SpaceX as an example, there are a lot of sub-MVPs that they need to build before they actually have an MVP that they can bring to market and see if they get traction. And so it would take them a long time before they actually even have an MVP. It seems to me that this conflicts with conventional wisdom, because conventional wisdom says that if you haven’t brought your MVP to market and tested it in, say, six months, that you aren’t being lean enough. But with SpaceX it seems that it may not really be possible to do. What do you think?
The Lean Startup by Eric Ries explains “MVP” as a broader concept of a tool to obtain validated learning. Getting traction is a special case of learning for companies whose most pressing question is whether people really want what they’re building. This special case encompasses most startups. But SpaceX had less doubt about demand for wildly cheaper launches and more doubt about technical feasibility, so an engine test firing was a kind of MVP for them.
I’m still not sure we addressed the question of whether there are times when MVPs inherently take a long time to build though. What do you think about that question? Sorry if you addressed it and I’m not understanding.
You can always chart a path that maximizes your rate of validated learning / de-risking your biggest risks. Like if you’re building something huge, build the most uncertain parts first. Yes sometimes a project is inherently slow and capital-intensive but that’s rare and most people who think their startup is that exception are actually just being sucked into the most common fatal attractor.
Whenever I ask any employee or contractor to do a project, I always say show me the first half-baked sign of progress after 1 day of work. I never want someone to do a bunch of work on a project that has any kind of risk without a quick feedback loop. I try my best to avoid trusting that it’ll all work out sometime later.
SpaceX’s goal is “settle Mars”, its MVP was “build a low-earth orbit launch system”, and sub-MVPs of that (experiments to validate the highest-uncertainty thing they needed to validate) consisted of things like engine test firings.
Using SpaceX as an example, there are a lot of sub-MVPs that they need to build before they actually have an MVP that they can bring to market and see if they get traction. And so it would take them a long time before they actually even have an MVP. It seems to me that this conflicts with conventional wisdom, because conventional wisdom says that if you haven’t brought your MVP to market and tested it in, say, six months, that you aren’t being lean enough. But with SpaceX it seems that it may not really be possible to do. What do you think?
The Lean Startup by Eric Ries explains “MVP” as a broader concept of a tool to obtain validated learning. Getting traction is a special case of learning for companies whose most pressing question is whether people really want what they’re building. This special case encompasses most startups. But SpaceX had less doubt about demand for wildly cheaper launches and more doubt about technical feasibility, so an engine test firing was a kind of MVP for them.
I see. That makes sense.
I’m still not sure we addressed the question of whether there are times when MVPs inherently take a long time to build though. What do you think about that question? Sorry if you addressed it and I’m not understanding.
You can always chart a path that maximizes your rate of validated learning / de-risking your biggest risks. Like if you’re building something huge, build the most uncertain parts first. Yes sometimes a project is inherently slow and capital-intensive but that’s rare and most people who think their startup is that exception are actually just being sucked into the most common fatal attractor.
Whenever I ask any employee or contractor to do a project, I always say show me the first half-baked sign of progress after 1 day of work. I never want someone to do a bunch of work on a project that has any kind of risk without a quick feedback loop. I try my best to avoid trusting that it’ll all work out sometime later.
Gotcha.