One of the many challenges that Product Managers face in trying to move organizations toward a more agile approach to product development is that some stakeholders simply don’t see the value in the shift. They believe that, since their way has worked for them for so long that there’s no need to change — after all, it can’t be broken if it works, right? But the simple fact is, the bad old ways of product development are dying, as markets and customers move faster and have more options available to them to solve their problems every single day. There’s not a single industry that isn’t facing high-investment newcomers who are able to move fast and adjust — and leave they’re slow-moving, waterfall-based competition in the dust.
The Product Lifecycle
This post comes courtesy of a direct request from one of my supporters over at Patreon, who asked me if I could give them a 10,000 foot-level overview of the Product Lifecycle from ideation to delivery. While nothing here should be terribly earth-shattering or world-changing, I think it’s important for us as Product Managers to stop on occasion and think about how things should work for us from the point of an idea to the days supporting a thriving product. So here’s my personal take on the subject — as always, if you have thoughts or comments, feel free to drop them here or hit me up on Twitter!
Understand the Purpose of Your MVP
The concept of MVP is an interesting one in the Product Management world — interesting, in that just like the role itself, it seems to mean something different to almost everyone that you talk to. On one side of the spectrum, you’ve got the Lean Product folks who seem to think that a landing page without any other context is an MVP; on the other you’ve got people who seem to think that you’ve got to have a full end-to-end solution that’s just ugly to achieve an MVP. The truth, however, lies somewhere in between the two — as I’ve noted before, there are some key considerations that come into play when coming up with our MVP (When is an MVP *not* an MVP?, but there’s more to it than just understanding the “Minimal”, the “Viable”, and the “Product”. Ultimately, MVPs must all serve some purpose; otherwise there’s really no point in it.
When is an MVP *not* an MVP?
For a term that’s so well-established in our profession and so widely used, it always surprises me when people abuse and misuse the concept of Minimum Viable Product (or “MVP”). It seems like such a fundamentally simple and clear concept, but often in practice it gets all wrapped up around the axles of internal struggles, until it no longer bears any resemblance to the basics of the concept itself. And when we abuse such a basic concept, bending it to our own purposes rather than using it for the purpose it was conceived for, we wind up watering down the meaning of the term and missing the entire point of engaging in the process of defining and building that MVP in the first place. We create MVPs to confirm a set of hypotheses, to ensure that the problems we’re trying to solve are real and valuable, and to make sure that the technology behind the solution functions as expected. At least, that’s the theory…here are some common missteps that Product Managers make that change their efforts from an actual MVP into something else.
Dropbox: The Most MVP of All MVPs
It’s constantly surprising to me that people seem to have such widely different ideas of what the term “MVP” or “Minimally Viable Product” really means. Perhaps it’s a result of the term becoming an industry buzzword, or perhaps it’s because it’s used in some very different contexts, but it always baffles me that people focus on the “minimal” part of the term and completely forget the “viable” and “product” side of things. To me, you don’t have an MVP unless you meet all three criteria:
- You have identified the minimum set of features necessary to engage your users and to solve their valuable problem;
- You have identified a way to ensure that your solution is scalable enough, stable enough, and valuable enough that you can confirm your product hypothesis; and
- You actually have something that you can sell, market, or test.
Whenever I think of what MVP means to me, I think of Dropbox, the cloud-based file-sharing system that pretty much encapsulates everything that an MVP should be.