How to Be An Engineer's Product Manager
Product Managers at tech companies are like bass players in bands:
- It’s easy to pick up the basics and fake it.
- You can get by doing the minimum required.
- You’re not always necessary – others can do the basics.
- It’s deceptively hard to get good at it.
- Great ones are easy to spot and lift up everyone else.
My advice for any would-be PM or Bassist (and note, I have been both):
Either put your direct team first, be widely hated, or find a different job.
I personally like my job, enjoy being productive and don’t want to be hated.
So here’s my guide on how to be the most productive and respected PM you can be – by working with and for your Engineering team – not against them.
Don’t try to out-engineer the Engineers
This should go without saying, but apparently it doesn’t: your job isn’t to impress engineers with your technical depth. And even if you are technically strong, your job is to create space for engineers to own the How — your job is the Why.
The good news? Engineers want help defining the Whys.
This is because they hate building things that don’t matter. They want to know that what they’re working on is solving the right problems.
If you ask smart questions that drive at discovering the Whys – they won’t give a shit that you’re don’t understand some technicals details as well as they do. In fact, great Engineers understand that being able to focus on customers and business outcomes without getting sucked into implementation details is in itself a super power.
And for the love of all that is holy, please don’t pretend to understand technical things that you don’t. Engineers can smell that shit a mile off. Instead, lean into their strengths and ask the important questions about the constraints, risks, tradeoffs that you need to know to do your job.
If you need to ask questions that could risk derailing the conversation or cause a big distraction, look elsewhere first. Some great external resources that even the most engineering-hardened PMs will use are:
- AI chat for the questions you don’t really know how to ask. As it can infer from your (poorly written) prompt and point you in the right direction (although you’ll obviously need to double-check answers for hallucinations).
- Seek trusted technical mentors (outside of your org) for getting more opinionated and pointed answers. Strong opinions will give you richer context.
However, what’s the single worst thing you can do? Block your engineers. That is the number one PM sin. So if you’re blocking, you better have a damn good reason — and ideally, a way to mitigate or workaround it.
Your job exists to help engineers ship the right thing faster. Full stop.
Bureaucracy and politics: Use sparingly, do so transparently
Contrary to popular opinion in 2025 – bureaucracy isn’t inherently bad. The word means “desk for storing rules” — a system for organising knowledge. And engineers love systems.
But what they hate is process for the sake of process. Bureaucracy that exists to justify your job, rather than support theirs.
So if you introduce a framework, explain why. If you ask for a details on something, explain what it will unlock. Only build systems when there’s a genuine, pressing need.
Politics and navigating org dynamics are sometimes a PM necessity and one that a lot of Engineers would rather avoid as they can. So when you can – handle this distraction and be clear about it. Let them know what you’re doing and why.
But keep it classy. Don’t engage in politics for your own ego, or to jump over people. Otherwise trust will break down. Do it to genuinely help your team move forward. Their success is your success.
Build Trust (and then keep building It)
PMs are universally mistrusted — and honestly, it’s well-earned. A bad PM often does more damage than a bad engineer. They can block work, misalign teams, make poor hypotheses …and then somehow disappear when things go to shit.
Some PMs fall into the role not because they love building products, but because (like playing bass!) it’s easy to get started.
Many are attracted to product management because it looks like a position of power. Spoiler: it’s not. And that should be by design.
The best PMs I know:
- Are super transparent with their teams.
- Ask how they can actually help.
- Share context and decisions early and often.
- Don’t mandate anything they can’t clearly explain.
- Make data-informed bets (even when the “data” is intuition + experience — as long as you explain why).
If you’re not sure what to do: default to honesty. Make your work visible. Let engineers opt into it. Be the person they want in the room when hard calls get made. Don’t be the person they have to protect themselves from.
Know that high-level Engineering concerns are your concerns by respecting developer experience (DX), automation, and infrastructure. These aren’t “nice to haves” or backburner work to push aside. They are force multipliers for the whole team. If Engineers are excited about improving CI or automating tests — listen. Understand why that work matters. These kinds of investments make every project faster, safer, and more enjoyable to work on.
If you want engineers to care about the problems you’re solving, you should care about the problems they’re solving too.
Afterthought: AI should be making bad PMs nervous right about now
AI isn’t going to replace all PMs — but it is going to replace the ones who add little value. Especially the ones who mostly pass tickets around or act like middle managers for engineering output. ‘AI’ in 2025 mostly refers to ‘Generative AI’. And you know what it’s really good at generating? Product specs, JIRA tickets and other artefacts that bad PMs have traditionally treated as their main currency for respect and promotion. Give. A. Fuck.
But great PMs? The ones who deeply understand the user and their problems. Or how a multitude of murky inputs combine into solid outcomes and strategies. Those PMs are still going to be valuable, at least for the foreseeable. Anyone can ask an LLM to write a product spec. Not everyone can look at that spec and say: “this won’t solve the real problem.” Or: “this won’t land with our users.” Or: “this won’t align with that.” At its core, generative AI is a probabilistic machine that might be able to guess the output. But you still need someone who understands the outcomes.
In summary:
- Be a good PM(Bassist), keep your job(place in the band) and have an enormous sense of wellbeing.
- Be a bad PM(Bassist) and risk losing your job(place in the band) to ChatGPT(the Keyboardist).