Someone writes in to support:

Can you ask your team to build a button at the top which on clicking will open a pop-up and let me input X?

A salesperson, after a demo, will say:

The customer said we should automate this step,” or “How about having a tracker Y?” or “We must build feature Z now! Our competitors have it.

As Product Managers, we often receive a lot of ideas from our users. These inputs vary. Some bring you ways to “build exactly this, in this manner.” Others leave it a little vague, “build something that does this behavior or takes this input-and gives that output.”

By approaching you, your users show they care. They believe these additions will make them efficient. Or your salespeople want these features built to close more deals.

These prescriptive nudges persuade you to think these inputs are important and urgent. It’s tempting to immediately take it up. But hold on a second! You must realize where these inputs are coming from.

Each of these individuals has their own biases, world-views, data-points, constraints, and assumptions. There are a few possibilities:

  • These problems could be minor issues.
  • These inputs may be symptoms of a larger problem.
  • You could be optimizing for the vocal minority. They may not represent the users who are in the most need of a better experience.
  • When you jump at solutions, you have not understood the problem. Addressing these problems at face value will only help serve short-term needs. They will help you achieve a local maximum. Nothing more. You need to remind yourself to not get too attached to these inputs.

How does one stay problem-focused?

How does one learn? Outlined below are a few steps:

  • First, thank them: When you receive inputs like these, be thankful for the inputs. Let your stakeholders know that you appreciate their interest in improving the product.
  • De-couple the problem from the solution: “You’re suggesting XYZ. And we know it’s a problem because…” “What convinced you that this was a problem? What makes it clear to you that this problem needs to be tackled?” Don’t prematurely affirm this to be the main problem. You are only mining for signals from this conversation.
  • Confirm this from your data: Treat these requests as a lagging indicator of your product. Your metrics and KPIs should guide you to build features. If someone is complaining about a login form, your metrics should reflect this as a friction point well in advance.
  • Record these inputs: Maintain a backlog of all the inbound requests you receive to get a gut feel of how many folks are asking for this. It would give you more data to confirm the size/value/urgency of the problem.

  • Frame the problem (together as a team): Don’t shoulder the burden of framing the problem yourself. Involve your team. The good folks from your dev, design, support, and documentation teams bring diverse opinions, perspectives, experience, and expertise.

    • What is the qualitative and quantitative evidence we have about this problem?
    • What gaps do we have in our evidence?
    • Is this a point problem?
    • Are we looking at it too narrowly?
    • Are we solving for only a specific segment of users?
    • Is it a frequent problem?
    • Is it an expensive problem?
    • Can we broaden our view of the problem?
    • What are our assumptions about the problem?
    • What alternate solutions exist?
    • What are their trade-offs?
    • What can we build that will maximize value for our customers?
    • What outcomes will each of these solutions yield?
    • How does this align with our team/company’s goals/mission?
  • Involve the initial stakeholders: Don’t assume that you have thought things through completely. What if there’s an unknown variable that you hadn’t accounted for? Business folks may not be great at defining end-solutions, but their inputs are valuable in shaping them.
  • Visualizing other dimensions of the problem and your solution: This will uncover latent aspects of the problem. If we built this in this manner, what are the dependencies? What technical challenges can we expect? What will it cost us to solve this problem? How will we know we have solved this? Is there a way we can quantify it?
  • Refine and rank: You have now decided what to build and how to build. How long will it take to build? Based on your situation, also decide when to build it (either in the next immediate sprint or at a future time).
  • Close the loop: Align your stakeholders (the ones who shared the initial ideas). If necessary, let them know what you went through as a team and what was finally decided.

In the end, it will be a subjective call with many trade-offs. Even after you have shaped the problem, at best, you have a set of hypotheses to work off of. You could frame your hypotheses in this manner:

We are going to do...
Because we see the problem of...
We know it’s a problem because...
If we don’t fix it, we’ll see...
We’ll know we’ve fixed it when we get...

In Conclusion:

When faced with situations like these, it is important not to feel pressured to rush to solutions. View the inputs offered as an intervention. View them as a gift in the form of an opportunity to better explore the problem space as a team.

Collaboration within product teams in problem discovery isn’t as natural as I put it. It takes a lot of time and effort to flesh out these conversations and align different stakeholders. And to make it more challenging:

Today’s solutions are only temporary.
Products evolve. Problem spaces evolve.
New ways of doing the same things more efficiently emerge.

Given these challenges, it is a miracle how software teams get anything done.