Practical Ways to Earn Respect as a Product Manager

I came across this tweet the other day from the former CEO of Bebo and still haven’t quite worked out what it means.

PMs are the bottled water of tech

— Shaan Puri (@ShaanVP) June 27, 2022

The responses in the comments demonstrate that the role of product management is still a hot topic; some people think product management is an essential part of the tech industry. Others think you’re better off without the overhead of people who actually ‘do’ very little in tangible terms (writing code, designing interfaces etc). And some think this means that product managers are harmful to the environment and packaged in garbage that kills turtles.

Indeed, in a day to day context, often PMs face a battle to justify their existence.

To some engineers, product managers are an extension of the management team, merely bleating out the requests of execs in a more formal way.

To some execs, product managers are an extension of the engineering team, merely bleating out the reasons why something that’s estimated to take 3 months can’t be built in a day.

And to some designers, product managers are bulldozers hell bent on destroying the scope of a design in order to get v1 out the door.

OK, they’re exaggerated examples but whatever the bottled water analogy means, it’s clear that to some, product management is a well respected profession, but not to everyone and that since the role of product is so nebulous, it can be difficult to justify your own existence. Luckily, earning respect from your peers can be a powerful way to fight off these feelings and misconceptions.

So if you are a product manager, what practical things can you do to earn respect in your day to day role? Let’s dig in.

Radical honesty – admit when you don’t know something

One of the fastest ways to lose respect – particularly from your engineering colleagues – is to pretend you know something when you don’t.

 Many engineers are equipped with a heightened sense of BS detection, and when you’re in the depths of a technical conversation about the feasibility of a new request or a technical challenge, if you don’t understand something, you’re far better off clearly stating that you don’t understand it. Attempting to wing your way through the conversation by throwing in a few buzzwords might make you feel like you’re contributing to the discussion, but most of the time it’s best to just admit you’re in over your head.

 I once worked with a senior product director who did not come from a technical background. In conversations with engineers, at the point where the conversation would get beyond the realms of her knowledge she would let the discussion continue but make it clear that at the end of it they would need a non-technical summary of the key challenges and takeaways. The confidence with which she clearly stated the point at which the conversation had veered too far into technical depths outside of her knowledge earned her a lot of respect. You could sense it in the room.

 Sure, engineers definitely respect PMs with deep technical knowledge, but in my experience you’ll earn far more respect admitting the boundaries of that knowledge rather than attempting to BS your way through conversations using buzzwords when you clearly don’t fully understand some of the technical concepts being discussed.

The same goes for non-technical things. If a team member asks you about a stat or a rationale behind a certain initiative, you’re far better off stating confidently that you don’t know but you’ll find out.

Confidence isn’t just reserved for the times when you know something; it can be most powerful as a way to express when you don’t know something. And in doing so, you inevitably earn respect.

Domain expertise

PMs will often come from varying backgrounds. Just take a look at the responses to this question:

What was your job before becoming a Product Manager?   — PM Diego Granados (@PMDiegoGranados) June 30, 2022 

 

 

 

Previous roles for PMs include:

• Customer service representative
• Poet
• Used car salesperson
• Strategy consultant
• Hardware engineer
• Solution architect

The paths to a career product are varied. And one of the most exciting and challenging parts of working in product is that no two companies are the same.

Throughout a PM’s career, they may find themselves working in financial services, logistics, ecommerce and consumer tech. In engineering (and to some extent design), many of the differences in industry domains are irrelevant to the core areas of your work.

An API in logistics will use similar technologies to an API in financial services. A react-based layout will work in the same way in ecommerce as it will in a consumer web application.

Product is different. Since a large chunk of product is about figuring out what users need or want and what you should build as a result, domain knowledge is essential. And the more knowledge you acquire in your particular vertical, the more respect you’ll earn with your stakeholders, team members and users.

This doesn’t mean that before taking on a new role in a new domain you must have domain knowledge, though. In fact, starting a new PM role with no prior experience in a particular domain can be massively helpful; you’ll have none of the pre-existing notions of how the industry ‘should’ behave – and you can use this lack of knowledge to your strategic advantage.

It just means you know your industry well enough for a team member to feel confident that you understand what you’re building will serve the needs of consumers in that industry.

Transparency

PMs spend a lot of time negotiating with stakeholders. And stakeholders like transparency.

Being transparent about why certain decisions were made or why something won’t be prioritised will earn you respect.

If nobody in your company understands why the product team is building something, particularly if they don’t agree with what’s being built for some reason, then you can almost guarantee that they’ll lose respect for the product that’s being built.

Being transparent about why the roadmap is what it is and why you’re chasing particular OKRs will help win over folks who disagree. And being transparent isn’t an attempt to make others agree with you (they might never agree), but in articulating your reasons why you’ve decided something, you’ll own it and earn respect as a result.

Know your numbers to be data informed

There is a subtle difference between being data informed and data-led. Data informed PMs will blindly follow the data, even if the decisions made as a result could have a negative impact on the overall experience of the product.

Example – Netflix auto play features

The Netflix auto play feature inevitably drives more view time and if you’re a PM chasing a key result relating to viewership then it makes sense to do everything you can to drive this number up. However, this manic focus on numbers at all cost also has an impact on the overall experience.

What if some users find it extremely annoying that episodes autoplay with the sound on full blast when you hover over them?

What if some users like to watch the end credits of a show and take a break between jumping into another episode?

What about the risks of digital addiction? Do we have a responsibility to ensure our younger viewers aren’t addicted to binge watching shows to the detriment of their mental health?

A data-led PM would make the decision to implement the feature anyway since it achieves the required key results. A data-informed PM would ask these questions before deciding.

Prompting yourself and your team members to ask these questions when deciding on product strategy and roadmap decisions may land you in difficulties with stakeholders who are equally obsessed with achieving key results, but just having the discussion is likely to earn you respect for thinking deeply about what you’re building.

Make decisions using product sense

Data-informed product people also know that sometimes the best strategic bets are the ones where your feelings or intuition tell you that it’s the right thing to do.

You might arm yourself with all the data and user research in the world but that’s still not a guarantee of success. In fact, arming yourself with data and research insights can cause you to fail spectacularly.

Example – New Coke

On April 23rd, 1985 Coca-Cola introduced a new version of their flagship product, aptly named New Coke. In the 15 years prior to the launch, Coke’s rival Pepsi was slowly gaining market share and consumer preference and awareness for Coke was declining.

The Coca-Cola company decided that something had to be done to fight Pepsi.

So they ran focus groups and user research sessions with over 200,000 people for the New Coke. Users said they loved the new formula and many claimed it was better than the original.

Armed with powerful research data, the company plowed ahead with its plans for a major new launch of the New Coke. The CEO echoed the sentiments of user research participants and described it as “smoother, rounder, yet bolder – a more harmonious flavor.”

Except that the launch itself was anything but harmonious.

Dedicated Coke lovers bombarded the company with angry complaints and it is thought that the company was receiving up to 8,000 calls a day.

Protests erupted around the US with some parents claiming that their children ‘will never know refreshment’.

Just 79 days after its launch, Coca-Cola announced that the old Coke flavour would be revived under the brand ‘Coca-Cola Classic’. And parents could sleep safely knowing that their children would indeed know refreshment after all.

This is a wild story, but the point is that no matter how much data and user research you arm yourself with, you’ll never know whether your product’s next launch will be a success until you’ve launched it.

And a sure fire way to earn respect as a PM is to firstly acknowledge that this is the case – and secondly, to develop and use your product sense to guide decision making.

In New Coke’s example, a PM with product sense might have asked:

What’s the psychological impact of killing a recipe that was drunk by Marilyn Monroe?

Do our existing customers care so deeply about our recipe that we might peeve them off by fundamentally changing it?

Are there alternative ways to stave off the threat from Pepsi which don’t involve changing our flagship product’s flavours?

Product sense is developed over time, with experience and a deep understanding of your market, your product and your users. Use it to inform your product decision making process and you’ll inevitably earn respect.

Be assertive

There are times when product managers need to be agreeable, patient and open to different opinions when deciding on strategy or what to build next.

But there are also times when PMs need to apply pressure and assert themselves.

In a product context, being assertive doesn’t mean being rude – it can mean having the confidence to defend a decision knowing that in doing so you will likely not make everyone happy.

It can also mean:

• Being super clear what’s not in scope for a first iteration of a product
• Providing clear feedback to colleagues and stakeholders when you think it’s appropriate
• Defending team members from undue criticism when you know they’ve worked their butt off to get something shipped

An assertive product manager is a well respected product manager.

Ship stuff

Practical theory is one thing. Shipping stuff is another. Don’t get too bogged down in the latest fancy frameworks or roadmap templates.

Stripe’s CEO says the company’s operating rhythm is ‘run’. His personal blog contains links to stories of companies who shipped products in record times.

According to a former Stripe employee, ‘run’ means:

• Moving forward with projects without waiting to hire the right people (and thus waste months)
• Doing worthy work now, instead of waiting to incorporate it in quarterly planning
• Consistently asking in meetings “Could we do that faster? What is the minimum increment required to ship? Could that be done faster?”

Ultimately, the best way to figure out if something is going to work is to ship a version of it as quickly as possible. And by adopting this mantra, PMs will gain respect.

Do what you say you’re going to do

One of Shopify’s product’s principles is GSD (Get Shit Done). And that’s one of the finest ways to earn respect.

Getting stuff done sounds relatively simple but often in reality it’s not.

But even more important than getting stuff done is the habit of doing what you say you’re going to do.

The quickest way to lose respect as a PM, or indeed as anyone working in business is to tell someone you’re going to do something and fail to follow through.

An old colleague of mine used to use the analogy of a battery. By following through on the actions you promised, your battery gets charged, but every time you fail to do whatever you promised, your battery levels deplete.

Engineers in particular, will remember each of the times you fail to follow through with even the simplest things like sending follow up notes, sharing a doc, inviting a colleague to a meeting or getting a data point you promised. And you’re doing yourself a disservice every time it happens.

As the old cliche goes, it’s far better to underpromise and over deliver than it is to promise the world and massively underdeliver. And hopefully by practicing each of these practical ways to earn respect, you can ensure your battery levels stay at a solid 90%+.

Because even if we are the ‘bottled water of tech’, at least we’re not New Coke.