Confessions of a Product Manager Lesson 2 — Quality is about getting the right outcome

My first lesson as a product manager was to focus on the problem, not the solution. However, as product manager, getting the solution right is still the key to success for a product.

Have you ever had too much conflict on building your chosen solution with the team? Have you had conflict with the designer and the engineer about the details?

The problem doesn’t lie in Agile or Waterfall methodologies. I have faced problems in both scenarios. The problem is that we put too much focus on requirements, specification and user stories. Which blinds us from the concept of success.

Conflict between Product, Design and Engineering

I can recall many gruesome meetings in both Waterfall and Agile methodologies when it comes to presenting the solution to an engineering team. I have been on both sides of the table too.

Imagine spending weeks researching and interviewing users to capture your requirements. Then many more hours in putting in a format that the team can understand. A Product Requirements Document (PRD) or in User Stories with acceptance criteria.

You spend a couple of more weeks working with a designer so that the solution is easier to see with a design specification. This interaction with designers is not one way. They are usually trying to understand the problems and researching in how users will interact and how it will look. Negotiations are done at this point. Finally your requirements and designs are ready for engineering.

Design Meeting with Team

You expect this meeting to go smoothly. Team understands what is needed to be done and go off and build it on time. This is where the real conflict starts. Every objection has an impact on the design and the solution. Every time you are questioned by your choices can undermine your influence with the team. Discussions about edge cases that may never happen wastes time.

This is great feedback, but the impact it will have is a new iteration of analysis and design before another gruesome review with the team.

Outcomes instead of Output

The biggest issue with specification and designs is that the focus on the solution and not success. In my first lesson I shared that we need to focus on the problem. This helped me communicate the problems for the team. How do I express success or the outcomes I expect? Most techniques I seen in the industry focus on Problem → Solution → Success. However, I overcame my challenge by looking at solving problems in a more pragmatic way.

1. What is the current situation? (Problem Statement)
2. What is the desired situation? (Success)
3. How will we help them get there? (Solutions)
4. What is stopping us from getting them there? (Risks and Constraints)
5. How will we overcome them? (Strategy/Plan)

What is the current situation?

I do research and interviews to find out what the current state is, their problems and how they overcome them. Every research and interview is documented as references. To the team I present:

• The Business Case or Problem Statement — The reasoning and the context of the problem.
• Current user flow (within or outside of the product) — To provide a better understanding of their tools and flows.
• Pain Points and Needs — To highlight areas of problems and their needs.
• Links to further evidence. I.e. research, interviews, the raw data.

What is the desired situation?

This is crucial information that determines if you are successful or not. This is agnostic to the solution you choose. I always try to write down measurable outcomes from the business, customer and user.

• Business Outcomes — Will we increase our revenue? Will we gain or retain customers? Will we save costs? How much should it cost to build?
• Customer Outcomes — Will we help our customer? Will we improve their revenue or savings? Will we help their productivity?
• User Outcomes — Will we help our users? Will we save them time in their jobs? Will we increase their productivity? Will we make them happier?

How will we help them get there?

I introduce engineers as soon as possible. Even at interviews and research. Although here I like to use their technical expertise and problem solving skills to help me.

I leverage designer’s ability to do design thinking to scale this out to the team. I have done Day 2 of Design Sprints that allows us to research existing solutions, generate many ideas and to learn from them to find the best solutions out there.

What is stopping us getting them there?

This is where conflict happens. However, conflict is healthy for a team. The main idea is that we have got to this stage early (saving costs and time), but also to be constructive so our solution balances the business, design and technical needs to solve the problem.

The idea is to review the top solutions and identify the risks and constraints. This allows us to adapt and improve our solution and come to a consensus to the best solution. I like to understand the following risks:

• Market Risk — Will the market adopt the solution?
• Value Risk — Will this achieve the outcome we expect?
• User Risk — Will the user be able to use the solution?
• Technical Constraints — Are there any limitations to the solution?
• Timing/Complexity Risks — Is the solution at risk of being delayed?

How will we overcome them?

As a team we have all the knowledge we need. The problem, the outcomes, the ideas and the risks. Now we need a plan to achieve success.

I like to take things one step at a time. If there are many market or user risks, I would mitigate them by doing user testing or getting feedback on prototypes.

If there are technical risks, I would plan more time-boxed research tasks for the team to tackle those risks.

If there is risks in timing or if our solution wont work, I would look at iterative and more frequent releases so that we can get feedback and make adjustments fast.

Building the right thing, the thing right and fast is the whole team’s responsibility

Requirements, Specifications and User Stories help engineers know what they need to build. But the responsibility of building the right thin is not on the Product Manager alone. This is a team responsibility.

The Product Manager should be responsible for the problems in the market, knowing what success is, understanding the risks and creating a strategy to be successful. If you do not know any of the above and focus on requirements only then you are more likely to fail, even if the team builds the requirements on time and in good quality.