The 3 R's of Product: Research, Research, and… Research
A Product Manager must look after the interests of his stakeholders, thinking about the consumer and developing the different phases of the creation of a new solution.
However, it's always worth remembering how important the Discovery stage is within these responsibilities. And when we are at this stage, the benefits of good research are enormous.
Let's be honest: day-to-day takes up a good part of our routine, the job to be done always weighs more than the analysis, and "what is urgent leaves no time for what is important."
As Product Managers, our heads are set on providing solutions and value, which is our North. Yet, do we take the time to investigate the problem or need, validate theories, and pivot when necessary?
Whether it is to develop a new feature or create a new product, our preliminary research will gravitate to the final result.
Mitigating risks
As the well-known phrase says, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions".
And that must be our pillar. Dedicating the necessary time to this stage will help us to mitigate four major risks:
- Value risk: if users will use the product or whether it solves their problem or covers their need
- Usability risk: if users can discover how to use the product and it is intuitive
- Feasibility risk: if the team can build what we need with the time, skills, and available technology.
- Business viability risk: if this solution enhances or leverages the various aspects of our business and is aligned with its strategy
Knowing the users in depth
Knowing users is essential on this path: what are their pain points, their needs, and their jobs and consumption habits? Only at this point will we be able to define our value proposition and what solutions we will propose to solve those pains.
And finally, market analysis. Who is doing the same or similar? Why would the customer choose us over the competitors? What is our differentiation strategy? Does the solution we will build have the business impact we expect?
Decision-making tools
Some practical tips that can help in our work and in the results we get:
- Each list of features, tasks, or improvements to be developed must be accompanied by the result we want to obtain (objective). In this sense, there has to be a macro plan that is fed precisely by that list.
- It is essential to consider other inputs when prioritizing, such as high-level effort estimations and validations with the technical team. They will help us measure the solutions' size to prioritize which ones we will focus on. You can use tools such as Impact Matrix.
- Never propose a single idea for a problem. The optimum is to propose several. Take the one we consider best meets our hypothesis and validate it with research, data, and the technical team. Suppose this idea doesn't give us what it was expected, or it must be deprioritized due to complexity and development time. In that case, we already have other ideas in the pipeline, ready to be tested. Here is a practical tool to take to action: Opportunity Solution Tree.
In conclusion
The temptation to fall in stakeholder requests or "solutions" is great: less rework, faster documentation delivery, stakeholder approval, and, ultimately, complying with what the client asks of us. There is no need to state that this is not sustainable: neither for the users, the clients, or our professional career.
We must always try to be one step ahead of events. And that can only be given by good research.
