Is ‘bias for action’ making product managers lazier?

Let me preface this by saying I’m a big believer in the  principle popularised 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 PMing. 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 summarise 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.

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 — 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.

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 2: BREAKDOWN
Step 3: IDEATE
Step 4: EXECUTE

PAUSE

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.

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.

BREAK DOWN

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.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.” —

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.

In the Indian startup ecosystem, people often refer to Flipkart’s  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  than online payments and scratch cards tend to be .

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 , , . Once the sub-problems are identified, start building hypotheses based on your understanding of the user base.

IDEATE

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

1. Ideas can come from anywhere. Proactively solicit inputs from engineering, marketing, customer reps, sales, and other functions in the firm.
2. Keep ideas limited to address a single sub-problem. Don’t go looking for a silver bullet. Ideas can be organically merged later.
3. Think laterally and freely (I find the  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 tear-downs, 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  for product managers who are just getting started.]

EXECUTE

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.” — 

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:To summarise, you can think problem-first by following this mental model:Pause and identify the underlying assumptions and constraintsBreak down the high-level objective into smaller chunks and build hypotheses for each sub-problemBrainstorm ideas to validate these hypothesesExecute shortlisted ideasIf you follow these 4 steps, your mind map will look something like this: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.