One article about why we should focus more on the outcomes rather than the outputs
It could be called “Start doing Product Discovery!” as well.
If your company or organization is not yet very familiar with the Product mindset and all the techniques and best practices it enables you, I bet you are used to working based on a Project mindset. You know, the classical approach where you receive a budget to do something, and you need to deliver that something after some amount of time, which is usually constraint by the original budget. So the project starts, you have risks along the way, the scope keeps changing (and so is the timeline), and after some (or many) postpones, you released what you were “paid for” originally. You finally do some postmortem meetings like lessons learned for example (which you never come back to it) and everybody is finally happy. Is it? Are your customers really happy?
The next step of this process is the endless list of production incidents, a broken relationship between IT and Business, and bad numbers on your CSAT and NPS scores. Then a new project starts again, to enhance the features that were not fully aligned to the users' expectations or to fix the huge list of tech debts. This time, however, you got less money and less time to work on it. And there's the loop.
As a Product Manager, the easiest piece is to get to know what needs to be delivered. The complex piece is to understand how that feature will benefit (or impact) the end customer. To write “As a user, I want to search by vendor name, so that I will find the active vendors.” is simple, but the hard side of it is to understand why my customer needs to search by Vendor name. What problems are they facing? What other information are they missing? How are they going to use that information after the search?
Also, it is not so uncommon that, at the end of a project, after the IT area delivered “what was asked for” by several different Business (and non-Business) Stakeholders, yet the end-users are not fully satisfied. Mainly because they were never (truly) consulted in the first place, and therefore their opinions were never accounted for as part of the process. So where did we fail?
Product Discovery
That happens because we are used to focusing more on the deliveries of the project than the outcome itself. We didn’t fully understand what the actual problem was and yet we went straight to the solution, assuming we knew what we were solving for. One key Product Management technique that helps mitigate this, but is commonly put aside is Product Discovery.
“Good discovery is continuous. The day we stop being curious about our customers is the day our competitors start catching up.” Teresa Torres, in the 6 Guiding Principles for Effective Product Discovery.
Product Discovery is a set of techniques in Product Management used to get closer to our end customers, (truly) listen to the problem they are facing, and validate different solutions with them through prototypes. If we never empathize with our customers and don’t understand the struggles they are facing, how come are we going to deliver good solutions for their problems? Also, who could better validate our solution than the end customers themselves?
To double click on the Product Discovery technique, here is a high-level explanation of what is done:
Empathize with the customers and understand their needs
As much as possible, avoid getting information second-handed. Understand what your customers are saying and complaining about; understand their daily-basis job and/or how they interact with your product; map their pain points and struggles. This step is about gathering feedbacks and empathizing with your users. In this step, we are not looking for solutions just yet (although we tend to naturally think about it), so it’s important to always ask them to focus on what the actual problem is, instead of having them giving us the solution.
Here we are curious about the “whats” and the “whys”, not about the “hows”.
Validate assumptions and mitigate risky paths through prototypes
Once we are familiar with the actual problem, it’s time to think about solutions and ways to solve it. Here is where the Product Team brainstorms some ideas and classifies those based on complexity and costs, trying to find the best possible solution that will solve the problem, having the lower cost possible. However, it’s important to make sure that this step is not an endless “Design by Committee“ type of session. Keep in mind that the best way to validate an idea is actually running it by our customers.
So here is when we need to start prototyping our chosen solution using mock-ups, sketches, etc. to validate it with the customers and close all the uncertainties and assumptions, preventing them from becoming risks later. Also, through prototypes is how our customers could try our solution and give us feedback about it.
Prioritize deliveries through MVPs
Once we have the feedbacks collected and a better view that our solution will address our customers’ problems, it is time now to start breaking and prioritize our solution into MVPs.
We may decide to onboard just a few users first to validate the MVP (maybe the same ones who tried our prototype), or enable it across, really depends on our strategy. The idea here is to have an open cycle of validation and feedback gathering with our customers, making sure the original problem is being solved.
Some challenges we may face during the Product Discovery process
If our company or organization is still heavily project-based, we may face resistance from the leadership or project stakeholders in doing this because it may “delay the delivery” or “waste people’s time”. In some cases, one stakeholder (or a group of them) may behave like a “gatekeeper”, making access to the customers difficult.
Another challenge we may face during this process is when we are back from the prototype phase and presenting the results and the feedback from our customers to the leadership and executives. Especially if we were given the solution in the first place instead of the problem, and the Product Team’s solution conflicts with the original idea.
As a Product Manager, our job is to make sure our product really solves our customers' problems. It is also about making our customers’ lives easier and giving them good user experiences.
Before spending thousands of dollars building something, we need to make sure we understand the outcomes we want to achieve, how to measure those, and how to make better use of our team’s time.
Have you spoken to your customer today?