Jeremy Jarrell

Agile Made Simple

Tag: mvp

Start with the Hypothesis, Not the MVP

Often when we think about an MVP, we think about a barebones version of our product that we can use to validate any hypothesis that we can dream up. But,…

Often when we think about an MVP, we think about a barebones version of our product that we can use to validate any hypothesis that we can dream up. But, despite the pervasiveness of this idea, it's backward thinking.

To understand why, let's consider the purpose of an MVP, in the first place. Remember that much more than merely testing our product, the true purpose of an MVP is to validate a hypothesis in the style of the scientific method.

But building your MVP before you choose your hypothesis is akin to designing your experiment before you consider what hypothesis you want to test. If you haven't chosen the hypothesis that you want to test, then how will you know what kind of experiment will best suit your needs?

To build great products, you must first start by deciding what hypothesis you want to prove and then designing the experiment that's purpose-built to validate that hypothesis.

Finding Your Next Hypothesis

So, where you do you find your next hypothesis? From your hypothesis backlog, of course. Your hypothesis backlog is a running list of unproven assumptions that you currently have about your product, which still need to be validated. These assumptions might include things like outstanding risks, unanswered questions, or unvalidated ideas.

Just like working from your regular product backlog, working from your hypothesis backlog is merely a matter of prioritizing by whichever hypothesis is the most important to you and then designing the MVP that best validates that specific hypothesis.

Making the Most of Your MVPs

But does this mean that you can have only one MVP per hypothesis? Not at all. While each of your MVPs should be purpose-built to test a given hypothesis, with a little upfront planning you can design an MVP that lets you simultaneously test multiple, closely related hypotheses.

The idea is not to limit each MVP to a single hypothesis, but instead to start with your hypotheses first and then design the MVP that is best suited to testing those specific hypotheses.

For example, in the image below you can see how Hypothesis1 and Hypothesis2 each map to a corresponding MVP. However, Hypothesis3 and Hypothesis4 are presumably so closely related that they can be validated using only a single MVP.

Creating a Culture of Intentional Experimentation

The key to shipping to successful products is not only to create an ongoing culture of experimentation but also to create a culture of intentional experimentation.

Teams who simply experiment wildly with little thought for how those experiments will contribute to their overall strategy rarely stumble onto the right product that makes their business successful. But, teams who take an intentional approach to experimentation and take the time to design MVPs that are best suited to validating each hypothesis are in a much better position to discover how to make their product successful and to do so much more quickly.

Are you new to the Product Owner role and are just trying to find your way? Or, are you an experienced Product Owner who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Product Owner and help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Start with the Hypothesis, Not the MVP

Why Your Minimum Viable Products Probably Are Not Viable nor Even a Product

Founders pay a lot of attention to Minimum Viable Products, or “MVPs”.  However, for all of the attention that’s paid there seems to be just as much confusion about what…

Founders pay a lot of attention to Minimum Viable Products, or “MVPs”.  However, for all of the attention that’s paid there seems to be just as much confusion about what an MVP exactly is.

Despite the name, MVPs aren’t intended to actually be viable products.  MVPs serve one purpose and one purpose only…to validate a specific hypothesis.  Sometimes that means you need to release a product to the market to validate that hypothesis, but usually not.

cup-of-coffee-and-napkin-sketchWhat this means is that most early MVPs actually aren’t viable in the marketplace.  In fact, they’re usually not even products.

Let’s dive a bit deeper into this.  Often when you first begin work on your product the hypotheses that you’re validating are less about specific features that would be tested with a build and more about your overall product direction or business model.  These are the “would you pay for this questions” that underly all assumptions about your product from the outset.  And, these are the most important assumptions that you need to be validating with your early MVPs.

So, how do you validate these early hypotheses?  You do so with the most lightweight MVP possible…a conversation.  You don’t need a functioning app, or even a prototype, to be able to have an early discussion with a potential customer about the validity of your idea.  Often, you just need a list of questions and a sketch on a napkin.  If this list of questions and sketch helps you to test whether or not your hypothesis is valid then this is your MVP.

Could this list of questions and sketch be considered a product?  Probably not.  Would it be viable in the marketplace?  Absolutely not.  But, it’s well suited to validating the specific hypothesis that you have at that moment because this hypothesis is about your overall vision for your product and where it fits in the market…not about specific features.

Meet the MMP

So, if an MVP is not always viable in the market then what is?  The MMP.

An MMP, or Minimum Marketable Product, embodies what people often think of when it comes to MVPs.  An MMP is the smallest possible product increment that could conceivably be viable in the marketplace.

Is a list of questions and a napkin sketch a viable product in the marketplace?  No.  But the first build of that product containing the bare minimum of features may be.  Often when we discuss adding only enough features into our product to create an MVP, we’re actually referring to an MMP.

All MMPs are MVPs

We use MVPs to prove a hypothesis that we’ve set for our product.  Depending on the nature of that hypothesis our MVP may be a sketch on a napkin, a landing page that collects email sign ups, or even just a cup of coffee and conversation with a potentialmvp-mmp customer.  It doesn’t matter what form they take, as long as they can be used to validate a hypothesis and move your product forward.

Once our hypotheses have matured to the point that we’re now testing actual features our MVPs start to become viable product builds, often in the form of MMPs.  Although an MMP will be more refined than the MVPs described above it can be just as useful for validating a hypothesis about your product.  The point we must remember, however, is that shipping a full fledged product to validate a hypothesis will take much more time and effort than walking a napkin sketch to a coffee shop.  This means that we should always be asking ourselves if we’re using the absolute lightest weight MVP possible to validate that hypothesis.

Choosing the Right Path

In the end, it all comes down to the nature of the hypotheses that you wish to validate and where you are in your product life cycle.   Early hypotheses concerning your vision or market fit can be much more effectively validated using a simple MVP.  This is because their lighter weight and more malleable nature will allow you to get feedback sooner and more easily adjust course if you take a misstep.  Later hypotheses concerning specific features, distribution channels, or platform decisions may warrant the investment in an MMP.  But your goal is to delay that investment as long as possible until you’ve proven as many of your initial hypotheses as possible using other means.

Want to learn more about how to create great products your customers will love? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Product Owner and help your team deliver the products that will truly value to your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Why Your Minimum Viable Products Probably Are Not Viable nor Even a Product

Beware Your Early Adopters

If you’re building a product then you want users…it’s that simple.   And you want these users as soon as possible because the earlier you can get users, the sooner…

If you’re building a product then you want users…it’s that simple.  

And you want these users as soon as possible because the earlier you can get users, the sooner you can get start to get that feedback that will be so crucial to your product’s success.

These first users are your early adopters and the feedback that they provide will be instrumental in the early stages of your product.  But as much as you need your early adopters there’s one thing that you must remember about them:  your early adopters are not your mainstream users.

Sure, there may be overlap.  And sure, with any luck, some of your early adopters will grow alongside your product into your mainstream users as your product matures.  But, more often than not, early adopters are an entirely different breed than your mainstream users.

Inside the Mind of the Early Adopter
early-adopter

Early adopters tend to have different needs than mainstream customers.  On the surface, both groups may be solving the same problems but by their very nature early adopters are more adventurous and are willing to put in more of an effort to do so.  And, while everyone wants a great experience, early adopters tend to be more tolerant of the occasional bug or odd usability choice.

But there’s an emotional component at play here, as well.  Often early adopters are just as attracted to your product for the fact that it’s new as they are for the underlying problem that it solves.  This newness is exciting in its own right and, in large part, drives their use of the product.  But this “I used your product before it was cool” quality isn’t a quality that you can count on to drive usage as a your product matures.

Inside the Mind of the Mainstream User

Mainstream customers are less drawn to a product for its newness but are also less drawn by the product’s feature set.  Since this may be surprising, let me explain.  Mainstream customers don’t buy a product because of its specific features, they buy a product because of the specific problems it solves.  This doesn’t mean that all of the same features that were compelling to early adopters aren’t also compelling to your mainstream customers, but it does mean that these feature aren’t likely to be the deciding factor to whether they make the jump.

Expanding on this, your mainstream customers will have much mess tolerance for the same bugs and usability issues that your early adopters had.  Whereas your early adopters viewed rough corners and hiccups with your product as a fair trade for getting access to a new and exciting product early your mainstream customers won’t be so kind.  These users will expect a complete and polished product that functions out of the box.  And, to the same end, while an early adopter may be willing to invest some time fiddling with and configuring their own experience, a mainstream customer will want an experience that fits their needs on day one.

Making the Jump

So, why does this matter?  This matters because if you expect your product to grow you’ll ultimately need to make the jump from your early adopters to your mainstream customers.  The catch, however, it that the same qualities that appealed to your early adopters may not entirely align with the same qualities that will appeal to your mainstream users.  Therefore, you may have to make the decision to alienate some of your early adopters, who have been with since the beginning, in order to grow to the mainstream.

To this end, you’ll also want to be cognizant of catering too much to the early adopters in your roadmap.  You’ll want to measure every step of the way once your product hits the market but beware of blindly following those metrics.  Don’t double down on features or trends that have had a lot of uptake in your product by your early adopters but aren’t likely to appeal to your mainstream customers.  By the same token, evaluate judiciously the decision to drop any feature with little uptake by your early adopters that potentially may be a play towards the mainstream market.

Product development is a journey.  On that journey you’ll encounter many customers all with different needs.  Don’t forget your early customers and the lessons they taught you at the beginning but don’t become trapped by those same customers, either.  By learning to tell the difference between the needs of your early adopters and the needs of your mainstream customers you’ll know when it’s time to take the next step in your product’s journey.

Want to learn more about how to create great products your customers will love? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Product Owner and help your team deliver the products that will truly value to your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Beware Your Early Adopters

Type on the field below and hit Enter/Return to search