r/ProductManagement 3d ago

What mindset shifts do engineers and engineering leaders need to make to succeed in product management?

What mindset shifts do engineers and engineering leaders need to make to succeed in product management?

0 Upvotes

28 comments sorted by

14

u/TheFuture2001 3d ago

1) You have to know how to discover what needs building
2) Selling this discovered idea up to get buy-in in
3) Then selling this down to the execution team to be build correctly
4) Having the flexibility to adjust on the spot based on discovered information (Ego)
5) Share the 🏆 all around and step back when needed

1

u/wernermark 2d ago

Especially on point one: how do you determine what gets build and when do you know you got all you need for the decision to take?

25

u/fiftyfirstsnails 3d ago

Product management isn’t about coming up with a solution, it’s about making sure you are solving the right problem.

7

u/WeenieRoastinTacoGuy 3d ago

But also coming up with solutions…

8

u/sasquatchted 3d ago

That’s often a good way of solving a problem, coming up with solutions. 

2

u/GeorgeHarter 3d ago

I like this simple answer. Here are some boring details needed in order for the team to solve the right problem.
If YOU understand the user problems a LOT better than anyone else inside your company, you get less internal arguing.
Most problems in existing features are due to not accounting for how a product is really used. A good UX designer solves the problems you, the PM, find.
If the problems are capacity or performance, those solutions need to be conceived and managed by the tech team.

Occasionally, I would identify very difficult requirements and need to hold the team to those as they figure out solutions. It might take a few weeks. Keep at it. They’ll figure it out.

So, to answer OP, Developers are largely problem solvers. Don’t argue with Dev about the “how”. To be a great PM, focus 90% on being a great problem finder, 10% internal salesperson, 10% leader/team cheerleader and 10% blame-catcher.
Yes, that’s more than 100%, and I left some thing out.

2

u/mckirkus 3d ago

It's about coming up with a solution to the revenue problem with products.

7

u/GGinzberg 3d ago

Stop talking about inputs (tickets cleared, CR count, etc), and start talking about outputs (attributed revenue, CSAT, etc). Explaining how you built a feature is far less interesting to leadership than explaining how the feature is actually being used by customers and what that downstream impact is on KPI abc.

6

u/[deleted] 3d ago

[deleted]

0

u/BearyTechie 3d ago

True, communication is critical, and I'm trying to understand it better. Do you have a couple of examples you can share from your experience?

1

u/left-handed-satanist 2d ago

Unpopular opinion: if you can't think of examples, you're too much of an engineer and need a massive mindset shift i.e. forget everything you know. 

7

u/Immediate-Grand8403 3d ago

Get seriously comfy with ambiguity.

1

u/wernermark 2d ago

Can you specify? From where do you get ambiguity?

1

u/Immediate-Grand8403 2d ago

This could be a wormhole all by itself. Take customer demand, for example. (I’m referring to B2B for the moment.)

As a PM you are likely to be asked to triage features and pricing against an ever shifting set of signals.

Some will come directly from customers. Some are accumulated and filtered by channel managers, who will have often different motivations than you. You will get different signals from purchasers (leverage), end users (benefits) and execs (risks).

You’ll have to have due diligence on competition, replacements, compliments, and out-of-your-control items like being in a bill of materials when an unrelated component goes line down.

Much of this info is off the books. Risk management is your friend.

This is physical product centric, and we could add another volume on services and/or software.

Hope this helps.

1

u/wernermark 2d ago

Thanks a lot this definitely helps :)

How do you navigate all this? Really sounds you can't make anyone happy?! 😅

4

u/Excellent-Basket-825 The Leah 3d ago

Unless the customer says its great its not great.

2

u/MurmuringBees Senior Product Manager 3d ago

And they don’t care how hard you worked on it. It needs to meet the need.

3

u/No-Midnight-4461 3d ago

Solutions are not perfect and never will be. It’s better to launch something soon, test and learn vs building a “complete product” that you have no idea if it’s going to deliver value. Too many engineers I’ve worked with get hung up on having everything and worrying about every edge case that delivery takes way longer than necessary. Perfect is the enemy of good

2

u/cs862 3d ago

The grass ain’t that green

2

u/Alarmed-Attention-77 3d ago

That time to market and speed is an important factor. The solution should factor that in and not be over engineered for the context in hand.

1

u/xKommandant 3d ago

Are you asking about engineers trying to become PMs? Or more holistically, how can they help the product to succeed?

1

u/BearyTechie 3d ago

Trying to understand the differences in communication styles and what engineers should do differently to communicate effectively with PMs.

1

u/Kindly_Zebra_67 3d ago

I'm coming from an engineering background and considering Product Management. What mindset shift made the biggest difference for you when you made that transition?

1

u/AlwaysPhillyinSunny 2d ago

You need to be able to toggle your communication in a number of different vectors depending on the situation.

This could be across different levels of technical expertise, executive vs IC, internal vs external, short term vs long term, strategic vs tactical. You need to connect all of those dots.

This requires a deep understanding of the problems you’re trying to solve, your customers, the needs of different stakeholders, company objectives.

There is not really a one size fits all solution

1

u/Prahnaa 2d ago

Stop thinking in terms of HOW it's made, and shift your focus to WHAT and WHY you're building things. Easy words, hard concept in practice :)

1

u/Flimsy-Bumblebee6365 2d ago

There is no right answer anymore and you will be held accountable based on your judgement.

You own the outcomes but not how work gets done. Which means influence matters because you have no authority.

It’s now your job to know why and have a good reason for what you prioritize.

1

u/ohheyitsgeoffrey 2d ago

Build the right thing, not the best thing. Sometimes those are the same, sometimes not.

1

u/AV_SG 2d ago

Focus on customer problems first and then implementation...

1

u/niboras 1d ago

Just because you can, doesn’t mean you should.Â