From Largest Potential Product To Smallest Valuable Products
How successful agile product development is all about maximizing the work not done
I believe that Scrum is a great way to create awesome products that are relevant, useful, and valuable to their users while at the same time generating revenue for their creators. Over the years, I’ve been fortunate enough to have worked on a variety of software products with several Scrum Teams. While some of those products fizzled out, many are still in active use.
While it sounds simple to “create a product”, everyone who has done so knows how challenging it is. It may be easy to look back on the development cycle with the hindsight of what the product actually became, but it is often far murkier and less clear when you’re in the middle of it.
The biggest challenge in Product Development is to distinguish between what the product can become one day, and what it should incrementally become first to validate critical assumptions that clear the way towards that future. And that presents a major struggle for Product Owners, customers, users, and developers as they are all inclined to spend most of their time thinking about the “Largest Potential Product” instead of the “Smallest Valuable Product”.
This post is all about that struggle.
For the remainder of this post, we use the term “stakeholder” with its intended definition; it covers everyone who has a clear stake in the product — either because they pay for it or because they actively use it (and preferably both) — and stand to lose when the product fails to deliver. Everyone else is just the audience.
What is a product, really?
While it is easy to get stuck in a lengthy debate over the most accurate definition of “product”, we think it is more helpful to look at it from the perspective of prospective users. In that light, a product is something that you create and provide to people in order to help them address a need they have or solve a problem they face.
Products will vary in how specifically they target certain needs and certain audiences. For example, Microsoft Windows is an option for whoever has a computer and is looking for an operating system to install things on. But Apple GarageBand is more specifically created to help people create music. There is also a transactional aspect to a product. After all, many products are provided in exchange for money, a subscription, personal data, or as part of a larger package. Even products that are solely for internal use, are created in exchange for the time and money that is spent on their development.
So from here, we have two unifying characteristics. The first is that products are defined by the needs they intend to address, and the groups of people they intend to address it from. The second is that, in exchange for helping users to address a need, there is always some exchange of value between those creating it and those using it — even when that transaction is done through intermediaries. A product can only be successful if it delivers something valuable to its stakeholders and those creating it.
“A product can only be successful if it delivers something valuable to its stakeholders and those creating it.”
When is a product valuable enough?
So what makes a product valuable to stakeholders? In an urge to get it right the first time, teams and organizations often pile features upon features in hopes of pleasing the stakeholders. But this necessarily lengthens the development cycle and vastly increases the risk of building the wrong product, wasting time and money on unused features, or missing new ideas altogether. At least, if teams do everything in one go and then release the entire product.
There is another way to go about this. Eric Ries popularized the concept of “Minimum Viable Products” with his book “The Lean Startup”. In it, he makes the case that when your aim is to develop a successful product, you need short development cycles, hypothesis-driven experimentation, and validated learning. In its more basic form, you create a product in small steps, where each step is used to gather feedback from actual stakeholders. This feedback is then used to verify assumptions (‘A user will like to solve problem X with this product or feature’) and perform experiments (‘Users prefer variation A of a feature over variation B and C’). When critical assumptions pan out to be false, the product strategy needs to pivot in order to survive.
It is important to emphasize that “Minimum Viable Product’” is plural, not singular. Although you may start with a bare minimum of a valuable product, there will be new versions of the product that add new features or extend existing ones. Building a “Minimum Viable Product” is not an end state, it is a learning process where new versions are continuously being delivered.
“Building a ‘Minimum Viable Product’ is not an end state, it is a learning process where new versions are continuously being delivered.”
It is also important to note that a minimum viable product is not a hacked-together, low-quality, barely working product. It is not a mockup of what the product will look like. It is also not a prototype that doesn’t really work. It is the smallest vertical slice that you can create to address a potential pain point of a stakeholder. This means that it works well, looks as nice as is necessary for customers, is tested, and does what it is supposed to do.
But where do you start? When is a product both as small as possible and still viable enough to address a critical stakeholder need? This challenge of “slicing your product” is at the heart of incremental product development.
An imperfect metaphor that still helps
One way to understand this challenge, and its potential solutions, is with a metaphor. A very common one is the development of a car in response to a need to “get somewhere more quickly than walking”. Now, this metaphor has some important caveats that we will mention at the end, and help us understand the challenge even better.
If your stakeholders want to get somewhere more quickly than walking, there are two ways to go about it. The first involves a clear end-state and a path towards it. You can start with a wheel (iteration 1), then add another wheel (iteration 2), add a chassis (iteration 3), and finish add windows and doors (iteration 4). Although we are building the car in steps, none of the intermediate results can be used by stakeholders. The individual iterations don’t deliver value to the stakeholders nor to those creating it.
An MVP-based approach could start you out with something smaller that still addresses the need to “get somewhere faster than walking”. For example, you may want to start with a skateboard. It’s definitely not a car, but it does address the customer’s needs. A point of feedback that we could get based on this minimum viable product, is that steering is a bit hard. A next iteration may turn our skateboard into a step. Based on the new minimum viable product, a user may learn that it is quite tiring to keep kicking with their feet. Perhaps we can concoct a different way to propel a human from A to B, leading to a bicycle. Now a bicycle may still be quite tiring for longer distances, making it useful to replace ‘human power’ with an engine. Eventually, we reach the car. Not because that was our initial goal, to begin with, but because that turned out to be the best way to address the customer’s need.
This metaphor helps us understand that we have to slice our product in such a way that we can release each slice relatively quickly and that it delivers value to both the stakeholders and to those creating it. Slicing into components (wheels, car, engine) isn’t helpful, but slicing based on needs is.
“Now, this metaphor works only on a very high level. It breaks down when you look at it more closely.”
Now, this metaphor works only on a very high level. It breaks down when you look at it more closely. For example, the learning trajectory isn’t realistic and rather wasteful. After all, skateboards, steps, bicycles, and cars require entirely different machines, skills, processes, and materials. Their markets of potential customers, and the competitors operating in them, are also vastly different. While the transition from “skateboards” to “steps” isn’t massive, switching from “steps” to “bicycles” moves us into a very different domain of products and competitors.
Still, the key point of this metaphor is that iterative development only works when it delivers incremental products that are both valuable to the stakeholders and those creating them. No stakeholder will be happy with just a car door. So the challenge is to find creative ways to slice up the needs of the stakeholders and start with the most critical ones, and then present the smallest possible product to address that.
Another key point is that the chances of success are higher when you don’t focus on the end product but on the pain points of stakeholders. No matter how awesome your product is, or how cleverly designed it is, if it doesn’t address a clear pain point it will not be successful. A minimum viable product is not something you create with a fully realized end-state firmly in mind, but as part of a process to measure, learn, and improve your product. A minimum viable product is also not the “first release of a product” (as Christo Meid suggested), but more a way of thinking about experimenting with, and learning about, what users need through experimentation rather than assumptions.
“No matter how awesome your product is, or how cleverly designed it is, if it doesn’t address a clear pain point it will not be successful.”
How do you identify valuable needs?
“Customers don’t know what they want” is a much-appreciated complaint by product developers (I have certainly made it on several occasions). And yes, while it is true that stakeholders often express their needs in very broad and vague terms, it also means that this kind of research is part of development. It is also why we firmly believe that Scrum Teams should be involved fully in this process, and not just delegate it to their Product Owner.
The field of customer research is a discipline in its own right that we can’t possibly do justice to with a few bullets. But here are a few things that we always find helpful:
- Go on field trips to where users of your product are, and learn from how they work and what they do. You’re likely to discover “pain points”; things that users try to do, or would like to do, but are either not possible now or very frustrating and time-consuming.
- Break down large and vague needs into smaller ones by asking questions like “Of all the steps involved in addressing this, which one can you do first without the others?” or “Of all the steps involved, which is the most frustrating one for you?”.
- Interviews your users to learn about their needs. What would they like to do, but can’t do now? What opportunities do they see for useful products? What can competing products not offer that they are looking for?
- If you have a hunch that you’re on to something, but you’re not sure if the need is really there, create a quick proof-of-concept and present it to a small sample of potential stakeholders. If they see the potential too, you can shore up the quality and the user experience and turn it into an MVP that you release to other stakeholders too.
- When you use Scrum, absolutely do invite users to your Sprint Reviews. It puts pressure on all the right spots — you want the increment to look nice, to work well, and to be bug-free — and you’ll get feedback from real users.
- Wherever possible, use your own product to better understand the needs of your product. This isn’t always possible, but sometimes you can find creative solutions to still use your own product.
No matter how thorough your research, the needs you identify remain assumptions until you test them with an actual MVP. For example, maybe there are not enough people with this need to make it feasible for you to create an MVP for it or to learn from it. Or the need may not be big enough for people to make the effort to download/try it. Or the need you identified is still too broad and big and needs to be broken down further.
We are always making these kinds of assumptions when we are building and designing products. This is exactly why we should try to validate these assumptions as quickly as possible. Taking a lot of time to build the best, most amazing product we can dream of is a waste if our assumptions turn out to be wrong. This does not mean that we have to discard all the crazy, cool, and amazing ideas that should be a part of the product at some point. But we should start with the ideas that we believe will help stakeholders the most right now.
What if stakeholders don’t like a “smallest” product
One of the biggest challenges I’ve faced in product development is a strong urge to get “it right the first time”. And this makes sense. When you launch a product with a lot of fanfare and it fizzles in the market, you’ve lost money, time, and goodwill. With smaller-sliced products, there is a (perceived) risk that users will try it once, not like what they see, and never return. So there’s an understandable sense of risk involved in big marketing campaigns for MVPs.
And while that risk exists for small products, it is important to realize that this risk is far greater for huge products where everything is put in to get it “right the first time”. When that product blows up, you’ll have lost a lot more time, money, and potential goodwill.
There are some helpful strategies to reduce this risk and facilitate learning:
- Soft launch your product without fanfare or wide-angle marketing campaigns. By not drawing too much attention, you can safely test your product with a smaller audience first. It offers a great opportunity to see how first adopters use and interact with a product. Once you are confident that it works, you can increase marketing activities;
- Use a public beta to draw in first-adopters and enthusiasts, before reaching out to wider audiences. Google has become famous for this by keeping Google Mail in beta for over 5 years while incrementally expanding functionality. Another example is obvious in computer games, where many games are released and iteratively developed in an open or closed beta before being released to the larger public. This often involves parts of games, like the multiplayer module or a part of the storyline. It helps game developers to determine if people like and understand the game, and what needs to be added;
- Limit the blast radius of your launch by launching a product in specific regions or for subsets of your stakeholders before scaling up. When the MVP works well in one area, it can be deployed to other areas as well;
- Don’t over-promise what you can deliver eventually. While marketing understandably benefits from a broader picture for your product than it currently is, the learning process of MVPs means that it is also unclear what the product will be one year from now.
Closing words
Successful Agile product development is all about maximizing the work not done for your product. Instead of adding all the bells and whistles that you can possibly think of, you start with the smallest valuable product first and grow from there. Instead of the “Largest Potential Products”, the challenge is to identify the “Smallest Valuable Product”. Good luck with that challenge!
