Quick Poll

Q4 is an interesting quarter. Some teams press harder on the development pedal to wrap up items to start the next year with a bang. Other teams become reflective & slow their build process to re-calibrate their strategy.

Here’s a little poll to understand where you stand in terms of planning for next year:

When is Product Management NOT the right job for you?

Here are some reasons people tell me behind why they want to get into PM:

"Better salary!"
"PM is less stressful than engineering."
"I don't want to code but I love to solve problems."
"I want to use it as a stepping stone to building my own company."

Journey — Sofware Engineer to Consultant to Product Manager | by Susmitha Burra | Product Coalition

Let me start by saying this.

If anyone thinks that product management is "easier" than their previous role, they are sadly mistaken.

Next, before you decide to switch careers, stop & think.

PM might not be for you if the following apply to you:

🚩 Ambiguity throws you off.

When I started my PM internship at Microsoft, I was told this:
"Aatir, we don't have a task for you. You need to find a problem yourself & then go solve it."

That's been the case all my career.

Nothing is given to you on a platter. Data isn't always available. You don't know if you'll have resources. Markets can be fickle. Customers change minds. Stakeholder expectations are fuzzy.

Yet, a Product Manager still needs to steer the ship in this fog of uncertainty.

🚩 Intense communication isn't your thing

A Product Manager is always trying to create shared understanding.

With stakeholders on what to expect, with engineering on what to build, with leadership on performance.

That's done through clear, consistent communication.

Yes. Think emails, Slack, memos, docs, slides, calls.

But that's not all. You need to be VERY comfortable with interruptive communication.

People will pepper you with questions at odd times. While you can choose when to respond, some of the fires will need immediate attention.

🚩 You can't let go of perfectionism.

PM is all about making tradeoffs.

You don't have infinite resources or time and thus, you need to sometimes let go of the "rough edges" to make way for something else.

You need to have a sense of "Good enough" & keep shipping.

🚩 Accountability & ownership scares you

In most firms, you'll be judged on outcomes.

While there is a case for inputs to be recognized, a PM still owns the end result, good or bad.

You may have built an exceptional UX, released on-time & thought out of the box. But due to externalities, your metrics went south.

You only earn the right to celebrate if the customer thinks you solved a problem for them & the business/product metrics support the theory.

🚩 Research doesn't intrigue you

Rule 1: You are not the customer.
Rule 2: Don't forget Rule 1.

A hard part of the job is to refrain from the temptation of self-projecting your own preferences.

You're in the driving seat but with many hands on the steering.

Sure, there is guesswork involved & you will need to practice best judgement.

But PM requires researching user needs. Tapping into feedback loops. Deciphering analytics. Not just "talking" to customers but ALSO distilling & extracting valuable insights.

Don't get me wrong.

Product Management is a fulfilling field. But it's not for everyone. And that's ok.

Thank you for reading Behind Product Lines. This post is public so feel free to share it.

Share

The difference between data-informed & data-driven

Here's how I learned the difference between data-driven & data-informed.

First, an analogy. Then, an example.

AN ANALOGY

In the mid-2000s, I used to work in Lahore as a software developer.

During those days, a certain political incident took place in the country. Security tightened up.

Now, my office was adjacent to some international embassies. It was no surprise that the route to our workplace was laced with new barricades.

As this news came by, I overheard engineering managers speculating how employee attendance would be affected due to this situation (remote work wasn't prevalent then).

Since teams had strict client commitments, they decided that, in case turnout was low, the alternative was to work over the weekend.

The next day, the managers were pleasantly surprised.

Barring a couple of exceptions, the entire team made it.

The conclusion was that the security traps didn't affect access to the office.

However, if you were to ask any of the employees, they had a lot of unpleasant stories to share - insane traffic, long lines, scorching heat, unreasonable questions at checkpoints, unnecessary hold-ups etc.

Attendance was full but employees had a tough time getting to the office.

AN EXAMPLE

While working on a classifieds product, I decided to change the ad posting flow based on feedback on how "long the form" was.

I decided to split the 1 long form into a 3-part flow: item details > photos > user contact info.

We were tracking around 30-35 ads a day. When we rolled out the feature, the ad volume dropped the first 2-3 days due to a bug but once that was fixed, we were back at the standard average of 30 ads/day.

I concluded that while the revised flow didn't increase conversion rates by much, it didn't break anything either.

However, when I talked to users in the community forum, I got a surprising response.

They were struggling with the new flow b/c:

more clicks involved compared to the previous
people on slower connections (especially those on mobiles) found the new flow took much longer to complete
users that were timing out on page 2/3 & had to redo the process
other edge cases like "the form(s) would reset on clicking back on the browser"

Now, why was the ad volume not dropping?

Because ad posting was a "critical path" feature.

The opportunity cost of "not posting an ad" i.e. not getting leads for their item was too high. Since users had a strong need to post, they were being forced to tolerate the additional friction.

This is just like how those office employees battled inconveniences to make it to the office b/c they didn't want to work on the weekend.

It’s like if you had to suddenly use a manual water pump to fulfill your drinking needs, you would resort to that out of necessity even though it would be inconvenient.

So, numbers alone didn't reveal the entire story. Going solely by the data, I'd have made a sub-optimal decision.

Data on its own has blind spots.

Decisions "informed" by data, user feedback & other evidence pools combined work far better.

Behind Product Lines

When is Product Management NOT the right job…