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.
At some point, every good Product Manager falls in love with their product. And after all, to truly realize your product’s full potential you often have to be its biggest…
At some point, every good Product Manager falls in love with their product. And after all, to truly realize your product's full potential you often have to be its biggest advocate.
But no matter how passionate you may be about your product, you must be careful not to confuse your product with your business.
Let's take a moment to understand the difference between the two.
Understanding Your Business Model
Put simply, your business, or more specifically your business model, is your means of generating the income you need to make your business successful. At a minimum, your business model describes the problem you're trying to solve, how you will solve it, and why solving it will be beneficial for your company. To understand this better, let's look at an example.
Imagine that you start a business reselling used textbooks to university students. To do this, you plan to purchase used textbooks from students at the end of each semester, store those textbooks over the semester break, and then resell those same textbooks at a 20% markup to a new group of students the following semester.
This approach is the essence of your business model.
Finding Your Product
But astute readers will notice one glaring omission from the model above: despite being a fully complete business model, there's not a single mention of a product. This is because the product that will implement this model is distinct from that model.
Let's consider what kinds of products might enable this model. One product might be a mobile app with a built-in bar code reader. A prospective seller might use that app to scan their textbook's bar code and instantly receive a buyback offer from your store. On the other hand, a prospective buyer might use this same app to scan the bar codes of books needed for their upcoming classes to check the availability and pricing of those books from your store.
But a mobile app is only one possible product that might enable this business model. Another possible product might forego the idea of a mobile app altogether in favor of a simple web app. Prospective sellers might enter their book's ISBN into this app to receive a buyback offer while prospective buyers could easily search your store's online inventory using an author's name or book title.
Each product has its own advantages and disadvantages. For example, the mobile app might be stickier for your user base leading to increased user engagement and ultimately higher sales. On the other hand, the web app might be more cost-effective to develop and maintain resulting in lower overall sales but a higher margin on those sales.
But despite their differences, what both of these products have in common is that either will fully enable the business model described earlier. So how do you know which product is the right choice for your business?
The Right Product at the Right Time
The right product for your business model will depend on many factors. For example, understanding how competitive the market is that you're moving into might influence how vital UX is to your product. Or, your business's financial constraints might impact how much capital you're able to expend on your product at the outset. Whatever factors may be in play in your business, those factors will influence which product is the right choice to bring your business model to reality.
But it's also important to realize that the right choice of product for your business is likely to change over time. For instance, a business that's light on cash may choose to initially enter a market using a product that's less compelling, but cheaper to develop. However, in the future, that same business may decide to replace that product with a more robust and feature-rich version once that business's revenue is stable enough to fund the development of that version. However, in either case, the specific product that the business developers is distinct from the actual business model that product enables.
Learning to Love Again
A hallmark of a successful Product Manager is a deep-seated love for their product. However, the product that you love today may not be the right fit for your business tomorrow.
Therefore, as a successful Product Manager, you must learn to love your product, but be careful not to fall in love with your product. Because while products may come and go, your business must be what truly lasts.
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.
This post originally appeared on the PivotalTracker blog. Ever get the feeling that your team is working on more than what’s actually in their backlog? Even with the best-laid plans, there…
Ever get the feeling that your team is working on more than what’s actually in their backlog? Even with the best-laid plans, there are still many tasks that can lie between the cracks, distracting your team from the work at hand. But even though you can’t see these tasks on your backlog, you can still feel their effects when your team struggles to accomplish the work already planned for the Sprint. In fact, because these tasks are often felt before they are seen, we refer to them as dark matter tasks.
In this post, we’ll learn how to bring these tasks out of the darkness and into the light so you can finally see which ones are holding your team back—and decide what to do about them.
Identifying the Symptoms
Although the existence of dark matter tasks may not be obvious at first, the effects of dark matter on your team are there if you know where to look.
One symptom of dark matter tasks is that your team seems to frequently refer to work that’s *not* visible on your Sprint Backlog during your daily standup. Or conversely, if your team restricts their discussion to items that are *only* on the Sprint Backlog, then you might find that they simply don’t have much to say at all.
You may also notice that much of the conversation that occurs naturally in the team room seems to focus on ideas outside of your team’s Sprint Goal. If this occurs, then this can also be a symptom that your team is occupied with other work.
Finally, another more obvious symptom is that your team regularly fails to achieve your predetermined Sprint Goal or forecasted velocity. In this case, if your team is regularly distracted by tasks that are not reflected on their Sprint Backlog, then you’ll often find yourselves without enough capacity to successfully deliver their defined Sprint Goal. However, remember that there can be many other reasons why a team might miss their stated velocity or Sprint Goal beyond dark matter tasks, so it’s important to thoroughly investigate any pattern of misses before assigning blame to a single root cause.
Bringing Those Tasks Into the Light
But once you’ve recognized that you have a problem with dark matter tasks in your team, how do you solve it?
If you’ve worked with agile methodologies before, then it should come as no surprise that the key to solving this problem is to make the work visible. And the best way to do this is by encouraging your team to add any tasks you’re working on to the Sprint board (if they aren’t already reflected there).
However, as simple as this sounds, teams are sometimes hesitant to do this. This often stems from a common myth that once a Sprint has started, it can’t be changed. But no matter how pervasive this myth is, it couldn’t be more wrong. Although we want to avoid changing the overarching goal for the Sprint after the Sprint has begun, regularly revisiting and refining the Sprint plan can actually be quite useful. Remember that the Sprint backlog is the formalization of your team’s plan to achieve their Sprint goal, if your team happens to discover a more effective way to reach that goal after the Sprint has begun, then why would we not change that plan in the interest of becoming more agile?
For this same reason, your team should not be shy about adding tasks that are distracting you from your Sprint goal, as doing so has two major benefits. First, adding a task to the backlog makes it visible, creating a more accurate picture of where your team is spending your effort, better enabling you and your stakeholders to make more informed decisions. And second, once estimated, the addition of this task forces both you and your stakeholders to recognize the impact that this new task has on your existing Sprint backlog. This can force the conversations necessary to decide whether this additional task is truly worth both the effort it will require, as well as the additional risk that your team will incur in your efforts to meet the Sprint goal.
Understanding the Impact of Dark Matter
At the completion of the Sprint, your team and stakeholders can collaborate to review any new tasks that were added to the Sprint, as well as which tasks were pushed to future Sprints as a result of those additions.
If even after adding these new items your team was still able to achieve your Sprint Goal, then your team is adapting your Sprint Backlog to meet emergent needs successfully. However, if the team missed your Sprint Goal after adding these new tasks, then your team and stakeholders need to have a frank discussion of the impact of doing so.
And remember, even though some of these tasks may seem small and inconsequential, don’t fall into the trap of assuming that they’re simply too small to add to your Sprint Backlog. Even small tasks can add up and the sum of those tasks can put your Sprint Goal at serious risk. Remember, If it costs money for your team to deliver, then it needs to be on your team’s backlog.
Encouraging Transparency with Your Team
A key tenet of all agile practices is transparency. But this transparency cannot be achieved without a clear picture of what your team is actually working on.
However, this picture can only emerge when your team’s Sprint Backlog accurately reflects the work you’re doing and how you’re spending your time. But by diligently adding these tasks to the backlog and surfacing them for all to see, we can bring these dark matter tasks into the light.
Want to learn more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
Today, there’s no shortage of discussion about the need for Minumum Viable Products, or MVPs. However, where MVPs might fit in your own product development process is often unclear. Remember…
Today, there's no shortage of discussion about the need for Minumum Viable Products, or MVPs. However, where MVPs might fit in your own product development process is often unclear. Remember that rather than validate your product itself, an MVP validates whether the need for your product exists, in the first place.
But if an MVP only validates the need, then how do you find the best solution to solve that need?
Every individual need can be filled with many possible solutions. So it's up to you to choose the best solution for both your customers and your organization. Finding the right solution is where a Minimum Marketable Product, or MMP, comes into play. While an MVP validates a specific need, an MMP validates your solution for filling that need.
Discovering Your Solution
A great way to discover that solution is to create several lean MMPs, each of which can be validated separately. How your users respond to each MMP can help you decide which MMP may lead to the best solution to your problem, and which MMPs may not be the right fit.
However, an MMP is much more than a vehicle for merely validating how your users respond to your solution; it can also validate the viability of actually delivering that solution to the market.
For example, your MMP might validate concerns such as the best distribution channel for your product, the technology stack for building your product, or the hosting platform on which your product will reside.
However, in addition to delivery concerns, your MMP is also an excellent vehicle for validating the broader economic concerns of your product. For example, your MMP can help you project the total capital expenditure required to bring your product to market. Armed with this information you can better decide whether investing in your product is likely to yield a positive return for your organization, or if there are other opportunities out there that may yield better results.
But remember that your investment in a product doesn't stop when that product ships. A successful product is a long-term commitment, and that commitment will likely require an ongoing operational cost to remain viable in the market, such as ongoing maintenance, customer acquisition, or hosting costs. The lessons that you learn from your MMP regarding concerns such your chosen technology stack or hosting platform will better inform your projections for the operational expenses required to keep your product happy, healthy, and humming along in the market.
Seeing This in Action
To better appreciate where an MMP might fit in your product development strategy, let's look at an example.
Imagine that you're interested in creating a product to help food connoisseurs find great new ways to indulge their palettes. You've already gone through several rounds of MVPs and have discovered that a validated need exists to connect adventurous diners with new and ambitious restaurants in their area. However, identifying the problem isn't enough, now you need to find the solution.
Learning From Your Early Experiments
For the first version of your MMP, you attempt to solve this problem with a single mobile app targeted at both restaurant customers and restaurant owners. While restaurant customers loved the convenience of a mobile app, especially the ability to find new restaurants while they were already out for the evening, restaurant owners struggled with the user experience of a mobile interface. In particular, many restaurant owners found the process of updating their own listing using the small form factor of a mobile device frustrating.
Learning from this experiment, in the next version, you decide to split the experience for restaurant customers and restaurant owners across two separate products. Specifically, you decide to keep the restaurant customers on the mobile experience that they responded to so well, but move the restaurant owner's experience to a traditional website that can be accessed more easily from a computer. This larger form factor and more familiar user experience, allows restaurant owners to update their listings more efficiently, which leads to increased engagement with your platform.
Looking Beyond the Product
However, the first two versions of your MMP have only helped to discover the best platform for filling the need identified by your MVP. Whether that platform is economically viable, remains to be seen. Moreover, this is exactly what you hope to solve with the next version of your MMP.
Early user interviews ruled out the possibility of your restaurant customers paying for access to your platform since from their perspective; your platform is simply an additional form of advertising benefiting the restaurant owners.
This realization places the burden of paying for your service directly on the shoulders of your restaurant owners. However, exactly how they are willing to pay for that service remains to be seen.
In the next version of your MMP, you decide to test a pricing model based on bulk advertising rates. In this model, your customers pay a bulk advertising rate, similar to the rate that they might pay for an ad in their local newspaper, to be listed in your app. The familiarity of this model, coupled with favorable pricing, leads to strong early adoption by your restaurant owners. However, the initial findings from this MMP reveal that while this model may be popular with your restaurant owners, the revenue that it generates is simply too small to support your platform. Therefore, you're forced to eliminate this pricing model as economically unviable.
Finding a More Promising Path
The results of this experiment show you that to support your platform, you need to charge premium advertising rates. However, your restaurant owners are resistant to this as they find it challenging to actually measure the impact of their advertising dollars on their business. But rather than give up, this revelation actually leads you to the underlying hypothesis for your next MMP.
In your next MMP, rather than charging your restaurant owners an up-front fee to appear in your platform, you instead charge them a referral fee for every customer who expresses an intent to make a reservation with their restaurant after discovering it in your platform. In this model, you present restaurant customers with a button in their mobile app which allows them to click through to a restaurant's preexisting online reservations service. This click-through allows you to track referrals of restaurant customers who show an intent to book with the restaurant, which demonstrates clear value for your platform to the restaurant owners and justifies the premium advertising rates necessary to evolve your offering from just a compelling product to an economically viable and sustainable business.
Delivering a Viable Product
While your early MVPs can be very adept at identifying a need that's ready to be filled, MVPs often aren't refined enough to identify what product will best fill that need in a sustainable way.
However, by building on your early MVP experiments with a series of MMPs, you can more effectively learn which product will best meet that need, for both you and your customers, as well as determine how to deliver that product in an economically viable and sustainable way.
This is because in the competitive world of product development, simply identifying the need is never enough. To truly find success with your product, you have to identify the solution that will enable you to build a successful business for the long term.
Want to learn more about how to create great products with your teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your team deliver great products to your customers.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
Today, everyone is talking about Minimum Viable Products, or MVPs. Startups are planning their first MVP to bring to market. Established organizations are deciding when the MVP of a new…
Today, everyone is talking about Minimum Viable Products, or MVPs. Startups are planning their first MVP to bring to market. Established organizations are deciding when the MVP of a new initiative will be ready to launch. And even individual teams are wondering how many sprints it will take for them to reach their MVP.
But despite the number of people talking about MVPs, the entire concept of an MVP is often misunderstood.
The biggest reason for this is that we too often think of MVPs only as products. And this should come as no surprise, after all, since the name Minimum Viable Product even has Product in the name. But, in actuality, an MVP doesn't have to be a product, at all.
Identifying an Opportunity
Often, we think of MVPs as validating whether or not a product will be successful in the marketplace, but MVPs can actually come into play much earlier than this.
Great product managers know that before you can have a successful product, you must first identify an addressable need. An addressable need is merely a gap in the market that your organization is well-equipped to fill. Often this is done in the discovery phase of our product development lifecycle, but these findings can occur throughout the lifetime of your product.
But how do you validate whether not you've identified an addressable need? Luckily there are many ways to do this. The easiest way is to sit down one-on-one with the individuals whom you believe represent your target demographic and share your vision with them. To help facilitate this, you can share wireframes or paper prototypes of the product you envision, slide decks describing the needs your product will fill, or simply bring a list of questions designed to help you better understand the problems your target demographic is facing.
None of these techniques require you to write a single line of code, because none of these techniques require a functioning product. However, in every case, the artifact that helps enable that conversation, whether it be a napkin drawing, a slide deck, or even just a list of questions can be considered an MVP.
That's because the job of an MVP is not to validate a finished product, but instead to validate your next hypothesis, in the simplest way possible.
Addressable Needs, Prototypes, and Deep-Fried Dough
To better understand where an MVP might fit in your own product development lifecycle, let's look at an example.
Imagine that you've just moved to a new town and discovered, to your horror, that there's not a single donut shop in town. But, being the enterprising individual that you are, you sense an opportunity. You could open your own donut shop and bring donuts to your own corner of the world.
But where do you start? Well, as tempted as you might be to immediately build the donut shop of your dreams and stock it with your favorite flavor: A Triple-Strawberry Frosted Donut with Cream, you take a breath. Maybe there's a reason there's no donut shop in this town already. Perhaps the townsfolk don't care for donuts, or their stomachs can't tolerate fried dough. Or, perhaps the key ingredients are simply too expensive to import to this out-of-the-way borough. Whatever the reason might be, before breaking ground on your brand new donut shop you decide first to test whether there's even a need for donuts here.
Validating the Need for Your Product
How do you do this? Well, a donut is nothing more than a mass of fried dough. So, you first need to test whether your town has an appetite for fried dough, in the first place. The easiest way to do this is to simply create a ball of fried dough and offer it to your townspeople.
This ball of fried dough is your MVP. It's not a donut and certainly bears no resemblance to the donut you envision, but it does test the essence of a donut: deep-fried dough.
In this case, your MVP for a donut shop is not a donut but rather a device that tests the need for a donut, because without first validating the need for a product there's no reason to move on to validating the actual product in any form.
This is where an MVP really shows its value since MVPs are most valuable at validating the need for a product, rather than the product itself.
Filling the Need
After a short test, you discover that your MVP was successful…almost. While your customers loved the taste of fried dough, you made an unexpected discovery. The majority of townsfolk simply can't tolerate gluten; therefore donuts as you traditionally think of them are not an option.
However, this obstacle isn't insurmountable. With only a slight tweak to your favorite recipe, you discover that you can create gluten-free donuts. The result is a ball of fried dough that's not only tasty but also accessible to your entire customer base. What's even better, is that you discovered this before creating hundreds of your favorite, gluten-rich donut.
But as much as the townsfolk love the taste of your new gluten-free fried dough on their lips, you can't build a successful business on fried dough alone. You need a real product. You need a reason for customers to come through your doors. You need a donut.
But is now the time to bring your Triple-Strawberry Frosted Donut with Cream masterpiece to the world? Not quite. As encouraging as the results of your MVP were, you've only validated that there's a need for fried dough in your town. You still need to validate whether a donut is the right product to fill that need. So, in the spirit of taking small steps to maximize your potential for learning, you introduce the most basic donut you can think of: the Plain Glazed.
This Plain Glazed donut is your Minimum Marketable Product, or MMP. The MMP is often confused with the MVP but, in practice, they're actually quite different. While the MVP most often validates that a need for your product exists, the MMP validates that your product is the right solution for that need. However, as the name implies, rather than being your top-tier offering, your MMP is the simplest product that can validate that your product might be successful.
To design your MMP, you must first consider what the essential qualities of a donut are. They are made of fried dough, they can be held in one hand, and they have that oh-so-sweet donut taste that can't be found anywhere else. Your Plain Glazed MMP checks all of these boxes, so it's an ideal candidate for filling the need identified by your MVP.
Unleashing Your Product on the World
Once again, your MMP was a hit with your customers…almost. While your customers loved the taste of the donut and the ability to eat the donut with one hand, you discovered that most of your customers indulge their craving for donuts on the way to their workplace. Therefore, they can't risk the sticky glaze getting stuck on their fingers before an important meeting. But luckily for you, there's a simple fix. By simply removing the glaze from the outside of your donut, your customers can enjoy your delicious treats anytime and anywhere without the risk of a sticky mess.
Now that your MMP has proven successful it's time to move on to your product and unleash your Triple-Strawberry Frosted Donut with Cream masterpiece on the world. This is the moment where your wildest visions for your product can become a reality. And the success of both your MVP and your MMP have paved the path to this moment.
In some cases, your end product might closely resemble the first visions for your product that you had at the outset. However, in other cases, the lessons you learned throughout the entire process are likely to have influenced and helped to evolve your end product along the way. Regardless of where your path leads, clearly understanding the differences between your MVP, MMP, and your product will help ensure that your end product is something both you and your customers will truly love.
Do you want to use this image with your own teams? Click here to download a full resolution version of the donut image above.
Want to learn more about how to make agile work with real products? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of agile product delivery.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
