Describe to me how are you doing it today/last time you did it

The users’ ability to describe a problem and how they tried to deal with it indicates a number of things:<ul><li>It’s current</li><li>It’s bothersome enough to have the user try to solve it or at least experience it frequently enough</li><li>Possibly, they have a workaround, one that you can examine and indicate as a possible solution path (especially if more than one user is doing the same)</li></ul>

Following a few postings, I got some questions about managing the ‘noise’ product managers experience. I think it’s a topic that needs addressing.When I think about challenges to product managers day, I consider the non-scalable aspects they need to get ready for. (What I mean by non-scalable is this: think about departments that grow with the number of customers: sales, support, success etc. Product managers do not scale by customers, the technology behind the product itself is supposed to scale to serve the existing use cases. Product managers scale with new use cases and markets. The point is, growing number of customers means growth of inputs, with the same number of product managers). This is led by all of the insights originating from the market, competitive, sales/presales, support etc etc. All of those hopefully originate from users and prospects.Before we dive in, let’s put things in perspective. Lots of noise beats silence. It does need to get managed, processed, considered. Product managers need tools, automation, and time to do that. Modern tools do a great job at sourcing, recording, sharing and processing insights. <a href="http://www.productboard.com/" rel="noopener ugc nofollow" dir="ltr">ProductBoard</a> and <a href="http://www.aha.io/" rel="noopener ugc nofollow" dir="ltr">Aha</a>’s user portals are great tools to do that. If someone cares enough to search in the portal for the feature they want and vote for it, that’s best.But Not all insights come directly from users, and not everyone uses those tools. It takes me back to a time when access to users was indirect, through sales/presales/customer success etc. Remember the prioritization criteria “<a href="https://www.productboard.com/blog/5-mistakes-youre-making-with-feature-prioritization/" rel="noopener ugc nofollow" dir="ltr">the loudest voice in the room</a>”? That collegue who advocated empathetically that changing or adding something would enable them that opportunity that will allow the company 5X revenues, partnerships, IPO and whatnot, and save all the customers from churning?Those statements are never made with ill intent. But they are very focused and tactical. The product managers’ attempt at qualifying and validating those can meet some resistance. Maybe a lot. Friction created, and product managers find themselves in a difficult spot.What’s the solution? Qualification. Let’s make sure it’s real AND interesting. In the past, when product was unable to reach the user/decision maker directly, the idea was to ‘grill’ the audience. I’m sure many have a set of “you need to ask the user the following qualification questions”:<UL><LI>What is the pain/need?</LI><LI>What is the current state and why is it a problem (describe in details what do you have to do because of this issue)</LI><LI>Who cares and why (is there someone senior in the organization who is concerned about this problem so much that they are willing to invest in it, money, time etc.)?</LI><LI>What would happen if we solved this problem (how would your day change? what is the positive impact)?</LI><LI>What would happen if we didn’t solve this?</LI><LI>[INTERNAL to the organization] What is the merit or risk in the context of this problem? number of deals in the pipeline, total revenue, customers at risk.- Here’s the deal: it’s very rare that you can associate a feature directly to revenue (upside or risk). Again, inaccurate data leads to subjective arguments, resulting in friction.</LI></UL>etc. etc. Needless to say, these questions very rarely get answered.<figure><img alt="" src="https://miro.medium.com/max/500/1*cONUekKKFzr7xU5d9BgGr" width="200" height="200"></figure>Taking a chapter from <a href="https://www.producttalk.org/2021/05/continuous-discovery-habits/" rel="noopener ugc nofollow" dir="ltr">Continuous Discovery Habits</a> and focusing on one simple and clear question, that’s very easy for a user to describe:<BLOCKQUOTE>Describe to me how are you doing it today/last time you did it</BLOCKQUOTE>So powerful. Why?The users’ ability to describe a problem and how they tried to deal with it (as opposed to reading it off a 100 row excel of changes your product needs) indicates a number of things:<UL><LI>It’s current</LI><LI>It’s bothersome enough to have the user try to solve it or at least experience it frequently enough</LI><LI>Possibly, they have a workaround, one that you can examine and indicate as a possible solution path (especially if more than one user is doing the same)</LI></UL><figure><img alt="" src="https://miro.medium.com/max/500/1*2J7iiCyNBIkl9sN2EXL11w" width="692" height="409"><figcaption dir="auto">Product Discovery around user story mapping (image source: Caktus group)</figcaption></figure>Following this path, you get to better understand the details of their need/problem and discuss with them what parts of their journey is most meaningful, or alternatively, mitigation strategies. In other words, without committing to a solution or a timeline, you can identify what are the most meaningful experiments you could try to make it better. Those users then become your frequent feedback and validation team.This specific question is just one part of a broader <a href="https://www.producttalk.org/" rel="noopener ugc nofollow" dir="ltr">continuous discovery</a> approach, an approach that drives continued discussion and focus on the user. I highly recommend for product and dev leads to get the <a href="https://www.producttalk.org/" rel="noopener ugc nofollow" dir="ltr">book and get trained on CDH</a> to adopt the methodology.

Following a few postings, I got some questions about managing the ‘noise’ product managers experience. I think it’s a topic that needs addressing. When I think about challenges to product managers…

communication

Communication

entrepreneurship

Entrepreneurship

business

Business

startup

Startups

product

Product & Design

Following a few postings, I got some questions about managing the ‘noise’ product managers experience. I think it’s a topic that needs addressing.

When I think about challenges to product managers day, I consider the non-scalable aspects they need to get ready for. (What I mean by non-scalable is this: think about departments that grow with the number of customers: sales, support, success etc. Product managers do not scale by customers, the technology behind the product itself is supposed to scale to serve the existing use cases. Product managers scale with new use cases and markets. The point is, growing number of customers means growth of inputs, with the same number of product managers). This is led by all of the insights originating from the market, competitive, sales/presales, support etc etc. All of those hopefully originate from users and prospects.

Before we dive in, let’s put things in perspective. Lots of noise beats silence . It does need to get managed, processed, considered. Product managers need tools, automation, and time to do that. Modern tools do a great job at sourcing, recording, sharing and processing insights. <a href="http://www.productboard.com/">ProductBoard </a>and <a href="http://www.aha.io/">Aha </a>’s user portals are great tools to do that. If someone cares enough to search in the portal for the feature they want and vote for it, that’s best.

But Not all insights come directly from users, and not everyone uses those tools. It takes me back to a time when access to users was indirect, through sales/presales/customer success etc. Remember the prioritization criteria “<a href="https://www.productboard.com/blog/5-mistakes-youre-making-with-feature-prioritization/">the loudest voice in the room </a>”? That collegue who advocated empathetically that changing or adding something would enable them that opportunity that will allow the company 5X revenues, partnerships, IPO and whatnot, and save all the customers from churning?

Those statements are never made with ill intent. But they are very focused and tactical. The product managers’ attempt at qualifying and validating those can meet some resistance. Maybe a lot. Friction created, and product managers find themselves in a difficult spot.

What’s the solution? Qualification . Let’s make sure it’s real AND interesting. In the past, when product was unable to reach the user/decision maker directly, the idea was to ‘grill’ the audience. I’m sure many have a set of “you need to ask the user the following qualification questions”:

<ul><li>What is the pain/need? </li><li>What is the current state and why is it a problem (describe in details what do you have to do because of this issue) </li><li>Who cares and why (is there someone senior in the organization who is concerned about this problem so much that they are willing to invest in it, money, time etc.)? </li><li>What would happen if we solved this problem (how would your day change? what is the positive impact)? </li><li>What would happen if we didn’t solve this? </li><li>[INTERNAL to the organization] What is the merit or risk in the context of this problem? number of deals in the pipeline, total revenue, customers at risk.- Here’s the deal: it’s very rare that you can associate a feature directly to revenue (upside or risk). Again, inaccurate data leads to subjective arguments, resulting in friction. </li> </ul>

etc. etc. Needless to say, these questions very rarely get answered .

Taking a chapter from <a href="https://www.producttalk.org/2021/05/continuous-discovery-habits/">Continuous Discovery Habits </a>and focusing on one simple and clear question, that’s very easy for a user to describe:

The users’ ability to describe a problem and how they tried to deal with it (as opposed to reading it off a 100 row excel of changes your product needs) indicates a number of things:

<ul><li>It’s current </li><li>It’s bothersome enough to have the user try to solve it or at least experience it frequently enough </li><li>Possibly, they have a workaround, one that you can examine and indicate as a possible solution path (especially if more than one user is doing the same) </li> </ul>

Following this path, you get to better understand the details of their need/problem and discuss with them what parts of their journey is most meaningful, or alternatively, mitigation strategies. In other words, without committing to a solution or a timeline, you can identify what are the most meaningful experiments you could try to make it better. Those users then become your frequent feedback and validation team.

This specific question is just one part of a broader <a href="https://www.producttalk.org/">continuous discovery </a>approach, an approach that drives continued discussion and focus on the user. I highly recommend for product and dev leads to get the <a href="https://www.producttalk.org/">book and get trained on CDH </a>to adopt the methodology.

The single most important question product managers need to ask users

Macin Ma's ideas are part of this journey:

Related collections

Similar ideas