Confessions of a Product Manager Lesson 1 — Focus on the problem, not the solution

Previously in “Trust our Developers as Problem Solvers” and “Confessions as a Product Manager” I touched upon focussing on the problem since developers are natural problem solvers. However, I didn’t go into detail about why. There are two sides to this problem, giving information, and receiving information.

Influencing your team

My first lesson in becoming a Product Owner was how to influence a team of smart people to do what you wanted to do. No matter how experienced I was, I am faced with these issues every day. When I started with “what” I wanted, I ended up in long discussions going over the scenarios and the problems we’re trying to solve.

I recently attended a kick-off meeting where I, as an observer, saw the product owner face the same challenges as I did. The PO walked in with a clear idea of the solution, went through a grueling session about the problems and how he got to the solution. The meeting ended positively, where the whole team had left with a clear idea of the problems, but at the same time opened up the possibilities of better solutions.

Starting with “What” creates defensive teams. Starting with “Why” will bring your team on your journey to your solution. In this situation, if the kick-off meeting was to go over the problems the team and the team would have left understanding the problems and less tension for all.

Asking Questions

Not only are you solving problems that already exist, but you also listen to your stakeholders in what to do next. In any request or conversation, you will realize they do not naturally start with “why”. It is our duty as product people to truly understand why they are asking in the first place.

If a customer says, “Where is the documentation?”, do not send them a link to the documentation. Ask “why couldn’t you find the documentation” or “where did you look”. This information is providing you context and knowledge about the problem they face.

If there is a feature request, ask why they need it. Get to the root problem. Why? Our customers know when they have a problem, they do not know if the solution will solve their problem unless they can see or feel it.

What I try to do:

  • In feature requests, ask why 5 times. Record the results, this is useful evidence when you decide to pursue this problem.
  • Before designing solutions, interview your users and customers about the problems. They know about their pain, problems, and needs. However, they do not know if the solution they suggested will actually have an impact.

Focus on the Problem

Simon Sinek put me on the path of starting with why. I still have a conflict or difficult situations. However, I feel I am equipped with the right knowledge because I focus on the problem. What I do differently now is:

  • Start with why when communicating to anyone about the product, feature, story, etc.
  • Ask why all the time like a child who is exploring the world.
  • Learn everything about the problem. The impact, the user journey, alternatives, any evidence to support it.

More Stories

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Researc.her — Fang Chen

A room for understanding and RESTING — Bedroom

The Story of Waveblocks

Build a website using wordpress

3 Ways To Drive Value When Design And Analytics Collide

free project management software varanasi

free project management software varanasi

How to use Virtual Reality in the presentation of architectural projects

Measuring the Value of Public Space

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gino Toro

Gino Toro

More from Medium

Backlog: Keeping it Moving

Professional Product Management

Top 12 Product Management Books You Must Read in 2022

Five Pillar Strategies of Project Management