In the world of Product Development, there are only two big problems which need to be solved:
- Are we building the right product?
- Are we building the product right?
There are many approaches that help the developers to build the product in the right way, enabling great quality. However, building the Right Product is often challenging because it is not an issue of capability or technology, but more often it is an issue that stems from a lack of understanding or working with assumptions.
Product Owners, if working with untested beliefs about users, the market, and product, can lead to wasted resources, missed opportunities, and ultimately, product failure. In this article I explore 5 simple approaches to building the right product and focusing on creating business value.
What is the Right Product?
IMHO, a product that satisfies the needs of a customer or solves a problem while improving their satisfaction levels and in turn generating revenue for the creator is a Right Product.
We all have come across the image - a tree with a swing - that highlights the miscommunication in traditional product/project management. If you haven’t, just search for ‘project miscommunication images’ and it will pop right at the top of the search results. Here is my artistic take (with help of Gemini generated images) on the same thought.
Ah! I just love food. But take a moment, what if…this really happened at your favorite restaurant? Would you be happy as a customer? Would you go back to the restaurant again? Maybe. Speaking for myself, I might avoid the restaurant forever.
In this example, the stakes might not be too high (probably); but in your software product development it's not the same thing. At the restaurant, if you don’t like the food they can quickly fix another menu item for you. Can we quickly build another product for the end-user? I'm not so sure about that, even with all the vibe coding that is happening.
Hence, the Product Owner must understand that the cost of not validating assumptions can be catastrophic. Spending months building a product based on the assumption that users need a particular feature, only to find out later that they don't. This not only results in a financial loss but also damages the credibility of the product organization. By embracing a culture of continuous validation, Product Owners shift from a "build it and they will come" mentality to a more customer-centric approach. This empowers Product Owners to build with confidence, pivot when necessary, and ultimately deliver products that solve real-world problems.
5 basic and simple tools to build the Right Product
Paper Prototype
Yes, this might sound old school yet it is a very powerful technique to validate any assumptions that we have about the product. All you need is - chart paper, a few sharpies and a bit of sketching-cutting skills. Draw your screens on the chart paper and take it to your possible customer. Give them a walkthrough of features; capture their reactions and feedback. If they find it useful you can go ahead and build it.
If you think Paper Prototype is not for you, well no problem. You can also use tools like Figma to create some hi-fi prototypes/wireframes pretty quickly.
Example Mapping
Example mapping is a great approach to create a shared understanding. It's often used to understand the rules and scenarios of requirements from the customers perspective. It can be effectively used to help your customers to give an example of how the feature would work. Having an example often helps people to clarify any doubts or think of challenges which were earlier missed.
An example of example mapping:
Let’s say you want to build a basic user authentication system and you want a Two Factor Authentication, the example scenario would be:
- User receives an OTP on SMS
- User receives an OTP on Email
- OTP will be numeric like ‘346145’
Behaviour Driven Development
This is another good approach to build the right product. BDD supports ‘domain specific language’ Gherkin that allows business and technical folks to use simple English terms to define the desired requirement that is easily understood.
For example:
Given I provide the username
When I opt for OTP based authentication
Then I should receive an OTP on SMS
Hypothesis Driven Development
As the name suggests, Hypothesis Driven Development, is all about working with a Hypothesis. A good approach for this is to use the Test Card and Learning Card from Strategyzer. The idea is pretty simple. On the test card we present the Hypothesis that we believe would add value to the product. We also establish how long we want to run the experiment to validate the hypothesis and how we will measure it, what will be our key metrics.
Once the experiment is executed, we fill up the learning card with the insights generated and that helps us to determine whether the assumptions were correct or we were off the mark.
Explainer Video
Last on my list, is a simple explainer video of the feature that we would want to build into the product. Put that video on social media, add a metric like upvotes and decide if the feature that we assumed will add value does so or not. If there are more upvotes then our established threshold then let’s build the feature, if not then pivot.
Conclusion:
In a dynamic market where competition comes from all directions, it is highly insensible to build products or services without validating that the product or service creates desired outcome or impact for the user or the organization.
A Product Owner's job is to maximize the value of the Product. It can be done by “NOT” building a feature or product or service. Or, if we decide to build the feature, then that decision, those assumptions need to be validated or supported by empirical data.
P.S. If you are interested to learn more about Product Ownership then look at our offerings for PSPO and PSPO-A.