Product: What does it mean to “Listen”?

In this first part of a two part series on product management core functions, I want to discuss one of the most fundamentally important parts of the job, listening.

So, what does it mean to listen? When someone is telling you their problem, many times it is a problem that has been occurring frequently. It is very important that you let the user/stakeholder get it out. Many times, being a product manager is being that receptive ear that shows them you care and you are considering the issues. When you are working through interviews and learning the challenges, there are five things I would focus on.

Length of meeting

Be sure you set enough time to fully understand the issues. I like to make sure that 90% of the time in interview meetings are spent listening. Most of my talk time is spent digging into the problem. Be sure to set at least an hour to discuss the issue and the majority of the time should be hearing the issues and establishing a dialogue. This sets the stage for success.

Focus on “pain points”

Usually, I take the notes and hit the typical flag words for a PM. Any words that illicit an emotional response. Think of it like you would write a user story or positioning statement “As a user, I am frustrated by…”. It is important to capture those statements and reflect on them when thinking through priorities. Also, make sure that you ask how the issue impacts the business (time, are there workarounds, etc) because that is essential to prioritization.

Empathize with your stakeholders. Never be defensive or give excuses. Let them know that you understand the impact on their daily lives.

Stop trying to solve the issue / Promises

I have seen it. I have done it. You want so bad to solve the issue that you start explaining solutions. As enticing as it is, you have to resist the temptation. Focus on understanding the problem, not trying to fix the symptoms. You inadvertently make implied false promises. Perception is reality so even if you do not specifically promise anything, users will assume it.

You have a responsibility to all parties in the product lifecycle. Stakeholders, the business, your dev team, they all rely on you to be transparent and honest about the future of the product. By keeping “roadmaps” light and short, you allow for changes in priority and fewer broken promises. I use, what I call the “hurricane model”. Your cone of uncertainty will expand as you move out through time. In the image below, you can see the bands of potential to complete. Ideally, each circle will also be a certain size to define the amount of work necessary to complete the task.

Keep discussions light on deliverables and add your requests to the right side of the cone as priorities become clear.

Follow up quickly

After you have a chance to digest, consolidate with other requests, quickly respond to the stakeholder with progress on their issues. Even if it is just to let them know you don’t have enough interest to focus on the work, they should feel that communication channel. Always communicate effectively and on a cadence that defines your role. Even if you cannot do the work, always let them know you it is out of choice and not because you forgot about the request.

In summary, the five things you need to focus on for every stakeholder interaction are:

– Set enough meeting time to listen AND engage
– Focus on pain points
– Don’t try to solve the issue
– Don’t promise
– Follow up quickly