Skip to main content

Cataloging problems

How do you do your job as a product manager every day if you do not know what problems you have set your product to solve?

One of the most important tasks of a product manager it to catalog problems that prospects / target user base faces.

Just follow the steps and you can get really good at it.

Step 1: Listen to potential users

When you go out to meet people - either potential users or potential customers - you need to listen to what they speak. If you are really good, write it down as soon as possible as you keep listening.

That is just step 1.

Step 2: Look at what they do

As they keep talking, chip in once in a while and ask them what they do and why they do what they do.

While this might seem an innocuous question, it is the most powerful question and has enormous power.

Reason: You are going to get actions from the customer.

Step 3: Listen carefully to the one key thing that they say they are actually looking for.

When customers actually demonstrate to you what they are trying to find out, they will keep pointing to a select few set of things or information that they are actually looking for.

That is the gold mine.

Step 4: Validate what you just inferred.

At times, it makes sense to validate it as soon as you have inferred it. At times it is best to get back and put together what you have.

Present it back and arrive at the one thing that is going to make a difference to him.

While the 4 step process might seem simple, it needs a lot of practice and needs some training.

If you do not have a problem catalog, it is time to start having one now. It is extremely powerful.

Comments

Popular posts from this blog

My Journey in Inquiry and Advocacy - An experience report

It is recently that I have consciously started practicing Inquiry. Let me explain. I am a consultant who constantly looks at the situation and comes up and implements the solution to progress from there. While I do that, I constantly use Inquiry as a means to progress - one of the key facilitation technique specifically in multiple stakeholder situations.

Principles for developing systems that are anti-fragile

I have been trying to make sense of what anti-fragility means and how do I use that in my day job. As a Business Principal, I tend to work with the abstract but orchestrate a program of work that needs details. This makes my job a little difficult in the terms of designing for more self-preserving systems that preserve the spirit of the abstracted strategy or vision. I came across an article from Daniel Russo on anti-fragility and his attempt at creating a manifesto similar to the manifesto for agile software development. For more reading on Daniel Russo, here is his profile:  http://djrusso.github.io More reading from his paper here:  https://www.sciencedirect.com/science/article/pii/S1877050916302290 This post is an attempt for me to understand what goes into developing a program that uses every opportunity to strengthen itself and achieve its objective - the vision.  I liked the approach of principles for developing systems that are anti-fragile. It is a very valua

User Personas

User Personas are a very good tool for the product owners, business analysts or product managers to be able to co-create with designers. It is predominantly a product of the user research and should not be an amalgamation of demographic data. It is the best way for us to list all scenarios that a persona would take when they want to attain a goal. It is predominantly used to build empathy with user, focus the team and build consensus in a large diverse stakeholder group. The website I referred to is here:  https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/