Your PM is Gone, What Now?
The tactical playbook for engineering managers suddenly doing product management too (spoiler: it's terrible, but survivable)
Your PM just got a better offer. Or transferred to that "strategic initiative" (translation: they're escaping). Or decided they need to "find themselves" on a three-month sabbatical in Bali.
Congratulations! You're now the proud owner of a product roadmap that makes as much sense as AWS pricing, a team of engineers who have developed Stockholm syndrome for Prometheus, and exactly zero product management support.
Welcome to hell. Population: you.
Here's how to survive without losing your sanity, your team, or your job.
Step 1: Accept That You're Now a Part-Time PM (Sorry)
Let's get one thing straight: you're not becoming a product manager. You're becoming someone who does PM work badly while also trying to do your actual job. It's like being asked to perform surgery while also doing the hospital's IT support. Now, if you’re one of those lucky bastards that you were able to manage an engineering team without having a clue about your product - tough luck.
Time to get a grip.
Start using your own product religiously. I know, I know, you probably think you understand it already. You don’t. Engineers using their own product is like doctors taking their own medicine: theoretically sound, practically terrifying. We like testing happy paths, not what our users will actually experience.
To have a chance at any redemption, block an hour daily to actually use the thing your team builds. Poking around like you're debugging won’t do you much, put in the effort to create real scenarios with actual jobs to be done that you’ll take for a test drive. For example, if you're building payroll software, pretend you're Sharon from HR who needs to explain to the CEO why the engineering team's salary budget exploded again. Walk through every painful step she would take. Feel her pain. Become Sharon.
But not Karen. Never become Karen.
While you’re using the product keep a "why does this suck" log. Document every moment you want to throw your laptop out the window. Think of this as market research disguised as self-torture. Your frustrations are probably shared by actual users, except they can't fix the code.
Make this a habit, not a one-time thing. Schedule two hours weekly for this masochism, set it as a recurring event on your calendar. Use some LLM-backed tool to generate user scenarios if your imagination fails you (it will).
Step 2: Build a Roadmap (Or At Least Something Resembling One)
A Google Sheet roadmap is infinitely better than no roadmap. And yes, I said Google Sheet, because we both know you're not going to learn how to use Jira roadmaps properly even though you’ve been using the tool for a decade. Honestly, who really knows how to use it, anyway?
You should know what your product’s/department’s strategy is. If you don’t I - brush up, right now. To avoid letting your people down, whatever roadmap that you build must map to strategy. Take whatever passes for your company's product strategy (if it exists and isn't just "grow revenue 300%") and connect each project idea to it. If you can't draw that line with a crayon, don't build it.
Once you have that laundry list of projects, find 3-5 people who won't lie to you and run your roadmap past them. Identify your most product-minded engineers. These are the ones who ask "but why would users want this?" instead of just "how do we build this?" Treasure them. They're rarer than software without LLM integration.
Also, talk to your manager (if they're competent), peer EMs who've survived similar disasters, that one UX designer who actually talks to users, or PMs from other teams who owe you favors. Their feedback will transform your roadmap from "obviously written by an engineer" to "surprisingly coherent for something written by an engineer."
Step 3: Figure Out Who's Doing the PM Grunt Work
Here's the uncomfortable truth: some projects need actual product work such as user research, design coordination, market analysis. You know, the stuff PMs do when they're not in meetings about meetings. And realistically, someone will have to do that work.
But it’d be a mistake to just dump it on a random engineer, especially if that’s not something that they want to do. So, find engineers willing to stretch beyond code. Your project leads need to understand they're signing up for more than implementing features. They'll be writing briefs, talking to users, and yes, attending design reviews. Make this explicit before they volunteer, unless you enjoy having your team quit.
Don’t reinvent the wheel, steal templates shamelessly. Don't come up with new product briefs from scratch like some kind of masochist. Find templates online, steal them from other teams, or beg that PM friend at another company. Fill in the blanks and move on. Remember: the engineering group are not PMs; you’re doing the absolute necessary work to ship something to users, not to be proud of that one product brief.
Lastly, accept that you're now a coordinator. You'll be sourcing designers, begging for their time, and negotiating with their managers. It's like being a talent agent, except everyone hates agents and the talent can quit anytime.
Step 4: Turn Your Engineers Into Mini-PMs (Good Luck)
The secret sauce is distributing the product pain across multiple people instead of concentrating it in one person (you). The truth is that the intensity with which the lack of PM will be felt on each workstream is inversely proportional to the seniority of the leader of each workstream. That’s why each workstream will need someone to bring the clarity on the problem that the workstream is solving
That’s why it’s good to partner your staff engineers with project leads for the heavy thinking work. Staff engineers are good at understanding how new features interact with existing systems, which is exactly what product managers pretend to do but with more buzzwords.
Putting the load of PM-ing projects on a single set of people can lead to overall unhappiness and kill the vibe. Rotate the responsibility. Don't burn out your best product-minded engineers by making them permanent PM substitutes. Spread the suffering evenly.
Lastly, grow your engineers to become product-minded. Trace the line between their wonderfully-architected code and the productivity of Sharon from HR, and why, as improbable as it sounds, someone pays for it. This takes time, patience, and probably alcohol. Not everyone will be good at it. That's fine, not everyone needs to be.
Step 5: Manage Expectations (Or People Will Eat You Alive)
Your team is shipping without a PM. The quality bar should stay high, but the context matters. If you don't set expectations, others will set them for you, and trust me, theirs will be unreasonable.
Do not apologize, but lead with a disclaimer. In every product review, design critique, and stakeholder meeting, mention upfront that engineers wrote the brief. This provides essential context rather than making excuses.
And when jerks come with their “feedback”, shield your team from them. When feedback turns from "here's how to improve this" to "this is terrible” it’s time for a reality check. Your engineers are already doing extra work to the best of their abilities, they don't need to feel bad about it.
Over-communicate, especially when things are going south. Use every channel available: Slack updates, email lists, 1:1s, team meetings, bathroom stall graffiti. Risk being annoying rather than leaving people in the dark.
Step 6: Build Systems or Perish
The longer you're without a PM, the more you need actual systems instead of heroics.
Document the shared PM responsibilities. Create clear role definitions for product work on each project. Write it down. Make it visible. When things go wrong (they will), at least you'll know who to blame. (That was a joke!)
Presenting and discussing with stakeholders is a valuable career skill for any engineer - so give them the opportunity to learn it. Establish regular reviews where your engineers present project status and create forums for decision making. This builds their product skills and creates accountability. Just don’t throw them to the lions - be there to support and take feedback on the chin for all of you.
Never stop using your product. The friction logging can't stop because it's your connection to reality in a job that's increasingly about managing other people's work.
The Things That You Won’t be Able to Solve
Your team can absolutely keep shipping useful features without a PM. You'll excel at improving existing workflows and solving known user problems. It’s the bread and butter of engineering execution. And it’s great, that stuff actually matters.
You'll suck at net-new product discovery, complex go-to-market coordination, and anything requiring deep user research. That's fine. Focus on what engineering teams do well: solving problems that are clearly defined.
Most importantly, your engineers will develop product skills they never would have learned otherwise. Some will discover they love it. Others will gain newfound appreciation for what PMs actually do.
The Uncomfortable Truth
Losing your PM isn't a disaster, but it's a stress test that will either make your team stronger or reveal exactly how dependent you were on someone else to think about users.
The system you build to survive without a PM will make you resilient when you eventually get one back. Your engineers will understand users better, your roadmap will be grounded in reality, and your team will be more self-sufficient.
Just don't tell your executives how well you're managing without a PM. They might decide you don't need one after all.
Want more unvarnished truth about engineering leadership? Subscribe to my newsletter for weekly reality checks that your bootcamp didn't prepare you for.
Let's connect: I share observations about the absurdity of tech leadership on LinkedIn. Follow along for more uncomfortable truths.