How Product Managers can Solve Problems by Focusing on Outcomes vs. Outputs

Ramanand Murthy
Agile Insider
Published in
10 min readMay 7, 2019


Photo by Olav Ahrens Røtne on Unsplash

Let me preface this by saying I’m a big believer in the bias for action principle, made popular by Amazon. I’ve used it as a guideline whenever I didn’t have enough data to make an informed decision.

A common interpretation of this principle is that product teams should spend more time launching products and less time in analysis-paralysis. This is because most software decisions are reversible and do not require detailed study. Makes perfect sense right?

Mostly, yes. But often, the spirit of this principle is misunderstood to mean — “Spend time thinking about the solution instead of wasting time in problem analysis.”

Combine this misinterpretation with considerable resources, and you get feature launches with no discernible impact. In other words, lazy PM’ing. In fact, I’ve encountered many product managers who think their job is just to generate new ideas.

While idea generation is important, it is just one part of the product management role. If I had to summarize the most important aspect of a PM’s job in one sentence, it would look something like this -

Match the right solution to a problem or objective given the constraints of time and resources.

Solution First Mindset

Note that I wrote ‘match’ and not ‘create’ or ‘develop’. In my opinion, solutioning i.e. the ‘How’ part of an objective is a collaborative exercise — where inputs come from engineering, design, business, marketing, etc.

A good product manager is able to solve the right problem and also solve the problem right.

Product managers who focus just on the second part of the statement have, what I call, a solution-first mindset. PMs with this mindset will churn out a bunch of features but will rarely create long term impact.

You can spot solution-oriented PMs quite easily during discussions. Let’s take a hypothetical scenario of XYZ, a company in the online tutoring space, trying to address their problem of low demand. This is a conversation between two employees tasked to solve this problem:

A: “We need to increase our customer base this quarter.”
B: “Ok, let’s change our website landing page.”
A: “How will the new landing page be better?”
B: “It will load faster and be mobile friendly.”
A: “Can we also make the design more appealing?”
B: “Sure. Let me talk to the designer and get back to you.”

No prizes for guessing that B has a solution-first mindset. Notice how quickly the solution was proposed and then the discussion was all about that specific solution. Of course, modifying the landing page could have been a perfectly valid solution. But only if the slow page speed or poor design was stopping users from becoming customers.

There could have been other problems, better solutions. But they were left unexplored because B focussed on immediate action.

I had a solution-first mindset for an embarrassingly long time. Product teams I was responsible for were creating output but there wasn’t much outcome. Fortunately, I sought out and received some great advice about building products from experienced PMs in the industry. That’s when I consciously shifted to a problem first mindset.

Problem First Mindset

I would like to pay-it-forward to the product management community by sharing the mental model I use to think problem-first.

Step 1: PAUSE
Step 3: IDEATE


The first thing PMs should do when faced with a problem is to pause. Don’t start thinking about the cool new ways you can solve the problem.
This is easier said than done though.

That’s because hardly anyone starts their career directly as a product manager. People transition into this role after spending some time as specialists — engineering, design, sales, etc. Having been on the execution side of things adds considerable value when working as a PM but it is also limiting in a certain way — there’s a tendency to jump to solutions. This tendency is further validated because thinking about solutions quickly is seen as a bias for action.

Resist the urge to dive head first into solution finding.

Instead, clarify underlying assumptions and constraints, think deeply about the problem, and ensure that you are aware of all the nuances. And that brings me to my next point.



No, I don’t mean emotionally. After taking a pause, the next thing which works for me is breaking a problem down to its core components.

Example of prime factorization

In mathematics, there is a simple concept called prime factorization i.e. breaking down a composite number into its prime factors.

I recommend following a similar approach when trying to solve a problem.

This method is helpful because an unintended consequence of solution-first thinking is a belief in the silver bullet fantasy.

“Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.” — Frederick P. Brooks, Jr.

If you find yourself thinking “I want to make a single product/feature which will solve the company’s biggest problems,” then you have fallen prey to the silver bullet fantasy. More often than not, this approach doesn’t solve the right problem.

Do NOT look for a single magic solution to the problem

In the Indian startup ecosystem, people often refer to Flipkart’s Cash-on-Delivery initiative or more recently, Google Tez’s scratch card rewards as silver bullets. Inarguably, these features have been critical tipping points for the respective products but they aren’t really silver bullets. Cash-on-delivery has a much higher operational cost than online payments and scratch cards tend to be exploited.

Products have to constantly evolve to solve problems for users and important problems tend to be nuanced. You can dissect a problem using techniques like 5 Whys, Funnel Analysis, Fishbone. Once the sub-problems are identified, start building hypotheses based on your understanding of the user base.


Most PMs are comfortable with this stage of problem-solving. Just make sure you keep a few simple guidelines in mind:

  • Ideas can come from anywhere. Proactively solicit inputs from engineering, marketing, customer reps, sales, and other functions in the firm.
  • Keep ideas limited to address a single sub-problem. Don’t go looking for a silver bullet. Ideas can be organically merged later.
  • Think laterally and freely (I find the SCAMPER technique useful). Keep the team’s current capabilities at the back of your mind but don’t get bogged down by the team’s limitations.

[ Side Note: As a PM, you should read… a lot. Read about UX teardowns, technical breakthroughs, industry-specific changes, design revamps, new ways to analyze customer data, anything which is remotely relevant to your domain. Reading is one of the most cost-efficient ways to come up with ideas. Here is my recommended reading list for product managers who are just getting started.]


Once you have your ideas listed, think about how and when you want to execute. You will want to prioritize and shortlist ideas based on the effort required, the urgency of the problem, and the potential impact it will have on the end-user.

Execution of an idea could either be to validate an unknown problem or to solve a known problem or somewhere in the middle.

“The confidence you have in i) the importance of the problem you’re solving, and ii) the correctness of the solution you’re building, should determine how much you’re willing to trade off speed and quality in a product build.” — Brandon Chu

In your hurry for action, you may fail to define success metrics for each idea. But listing the success conditions before launch helps you remain unbiased (no pun intended) about the feature’s impact.

The essential attributes of any idea are the problem it is addressing, the success metric, and the launch priority:

Essential attributes of an idea

To summarize, you can think problem-first by following the four steps in this mental model:

  1. Pause and identify the underlying assumptions and constraints
  2. Break down the high-level objective into smaller chunks and build hypotheses for each sub-problem
  3. Brainstorm ideas to validate these hypotheses
  4. Execute shortlisted ideas

If you follow these 4 steps, your mind map will look something like this:

Solutioning as a PM

To further illustrate this point, let me take the same example as above. XYZ is a two-sided marketplace which connects teachers and students for online tutoring. XYZ doesn’t have enough teachers to meet student demand and therefore wants to increase its teacher base this quarter. The primary mode of teacher acquisition is via facebook ads which redirect potential teachers to their website where users need to submit an application form. Applications are reviewed by an internal team and successful candidates are allowed to post their profiles on XYZ’s portal. XYZ wants to increase its teacher base this quarter to keep up with the ever-growing demand.

The underlying constraints would probably be ‘maintain the same acquisition cost per new customer’ and ‘no negative impact on retention.’ Now that we have these assumptions in place, let’s break the problem down.

Here’s the current acquisition channel in more detail.

XYZ’s teacher acquisition funnel

As we can see from this funnel, users are dropping off at every step — the most significant drops seem to be at the accept application stage (60%), the ad click stage (50% drop). There is scope for improvement at the website landing stage because users are clicking on the ad but aren’t reaching the website for some reason.

Based on the approach I suggested, we now need to build hypotheses for drops in this funnel (check out conversion rate optimization). But wait, are there any other channels which can be explored? An understanding of the user segment will help determine the answer.

Apart from Facebook, potential teachers use YouTube in their free time and also look for part-time opportunities on job sites. XYZ should be available where these users already are instead of waiting for them to come to XYZ. Also, existing XYZ teachers love the platform and are happy to recommend it to other potential teachers.

Facebook [Current Channel]

  1. Accept Application Stage

60% of applicants are getting rejected by the internal review team. This could be because the application quality is low, or maybe because the internal team has set unnecessarily strict guidelines for acceptance.
After discussions with the review team, it seems like the application quality is low. The application quality could be low because our ads aren’t targeted to the ideal XYZ user, or because the high-quality applicants are turned off by the value proposition or the ideal applicants don’t like to use the website.

Potential ideas:
- Check which Facebook ads work best for high-quality applicants and use variants of those ads only.
- Clarify value proposition with XYZ leadership team so that all teams know which customers to go after and which ones to let go.
- Direct applicants to an XYZ Facebook chatbot instead of the website and get the application submitted via a conversational interface.

2. Ad Click Stage
50% of Facebook targeted users are not clicking the ad posted by XYZ. This could be because the ad isn’t targeting the right user segment, or because the ad content isn’t appealing enough

Potential ideas:
- Modify Facebook targeting engine by adding more profile attributes of successfully converted teachers.
- Have a team create fresh content for ads every day so that potential users remain interested in the ads.

Youtube [New Channel]

1. Create existing teacher testimonials on Youtube.
2. Run ads on education-related Youtube videos.

Job Sites [New Channel]

1. Post jobs on popular job sites
2. Create a part-time job portal under a different brand name and direct eligible leads to XYZ

Referral [New Channel]

1. Provide monetary and non-monetary benefits to teachers for referring other users
2. Provide tools to teachers for sharing their success stories on social media.

As you can see, each idea addresses a subproblem. More ideas will emerge once other teams are involved. Based on XYZ’s capabilities and growth plans, these ideas will then get prioritized and executed.

Did you notice that changing the website landing page didn’t even come up on this list? Why? Because it doesn’t solve the right problem.

By allowing yourself to spend time in the problem space, you can avoid the solution-first mindset encouraged by the misinterpretation of the bias for action principle.