When a PM takes over engineering
A PM-turned-EM at Trustly shares what devs miss, what PMs want, and how to close the gap.
I’m always curious about engineering managers who didn’t come up the usual way. When someone moves through different roles (like product or design) or even careers before becoming an EM, they tend to see things that most EMs miss.
João Ramos, an EM at Trustly (a Swedish $1B+ startup), is one of them, and I invited him to share his story:
Most Engineering Managers come straight up through the dev ladder. I didn’t.
I started as a developer, moved into Product Management, became a PM Team Lead, and then made the jump to Engineering Manager. That mix gave me a rare perspective on how engineering and product can actually work together, and why they so often don’t.
At Trustly, I’ve spent the past two years putting that perspective to work. Here’s what I’ve learned so far:
How to teach engineers to think like product people
What PMs really want from their EMs
How to explain (and push back on) technical projects through a product lens
Moving from PM to EM
Two years ago, parts of our engineering org were in rough shape: critical incidents, shaky deploys, poor monitoring, and engineers who felt micromanaged.
At the time, I was leading a team of PMs. The VP of Engineering - whom I knew from my dev days - reached out and asked if I’d consider stepping in.
I said yes.
My first focus was stabilization - coming from Product gave me a fresh set of eyes on engineering problems. Together with the team, we shifted from firefighting to prevention - rolling out Argo for safer deploys, improving observability, and building a culture of testing from scratch.
Helping engineers think like product people
Then came the real challenge—and where my PM background really helped.
When you get deep into the product world, you understand that coding is the last piece of the puzzle, and not the center of the universe. Much before that comes the understanding of the problem we need to solve.
1. Don’t guess - have engineers talk with customers
We were planning a new feature the usual way - API first, expose it, ship. But before starting any implementation, I made it a practice to meet with some of the bigger customers to discuss their expectations with them.
We couldn’t have been more wrong in our assumption. This wasn’t what they had in mind at all - they all wanted something way simpler. They didn’t want to consume one more endpoint but instead have this feature exposed in a portal that Trustly offers and which they’re super familiar with.
Too often, engineers just code what’s written in user stories without challenging the underlying assumptions or deeply understanding user needs. Knowing how to validate assumptions with actual user conversations is critical.
To get the most out of customer meetings, I make sure we go in with a clear agenda and a purpose - whether it’s to validate an assumption, gather feedback, or explain technical constraints.
When it comes to involving engineers, I believe their time should be used intentionally. They don’t need to be in every meeting, but when feedback directly impacts a system they own or when we’re exploring a complex technical trade-off, their presence adds a lot of value, and it helps them build empathy for the users.
2. The simple questions we ask every time
One simple but effective exercise I use is helping engineers shift their focus from what they’re building to why they’re building it. Before starting development, we walk through questions like:
“What problem are we solving?”
“Why would a merchant pay for this?”
“Why would a user choose our product over alternatives?”
Even just asking those questions helps build empathy with customers and think about outcomes rather than features.
Another key part is guiding engineers to resist the instinct to build everything. Instead, we practice identifying a clear minimum viable product, MVP, together.
What’s the smallest, simplest version that delivers real value? Having your engineers involved in that process (instead of just getting a ready spec from the PM) encourages iteration, prioritization, and product focus.
3. After production
A critical part that is missing in many teams is ongoing engagement after a feature is in production. I try to prompt the engineers to look at real usage data, like number of transactions, error rates, or performance metrics, and make them think about details like:
Can we improve the user experience?
Are there patterns or peaks worth exploring?
Are our alerts and monitoring giving us the right signals?
This shifts the focus from just shipping code to continuously improving it. It builds ownership, encourages proactive thinking, and helps engineers see their impact through a product lens. Over time, they naturally start thinking more like PMs.
Insights from Managing PMs: What Makes a Great EM?
Being on the other side gave me an interesting perspective on what PMs consider a great Engineering Manager to be.
The answer is almost universal - they want EMs who not only manage the engineers but also someone who could support them and understand the business. When there’s a tech initiative, e.g. moving services to cloud, the great ones know how to explain the value that will be added instead of just saying it needs to be done.
This may sound obvious, but once you are really in the PM shoes, you understand how rare and critical it is. Not to say reasons just to get the PM of your back - but to truly understand what value it will add, and if not, be willing to push back against the engineer for that technical effort.
Dealing with tech-debt projects as an ex-PM
One advantage of my PM background is being able to clearly explain the value behind so-called “tech debt” projects. There’s no such thing as pure tech debt - every technical decision has product impact, and it’s always worth your time to articulate it.
Here are 2 examples of real tech-debt projects and how I’ve dealt with them:
Painful deployments
Our deploys were very painful. We had no solid strategy, just “all or nothing” rollouts, with homegrown scripts that were risky and hard to maintain. Since we were using Kubernetes, we wanted to adopt Argo Rollouts to bring structure and safety.
To a PM, features like gradual rollouts or one-click rollback can seem like technical nice-to-haves. But once I explained that:
It’ll allow us to release only to a small percentage of users
Monitor real impact
Revert instantly if needed
They understood how such tools protect both user experience and business goals.
It took time to prioritize, but sometimes the right move is to pause, fix the foundation, and enable fast, safe delivery at scale.
Building a risk evaluation system
On the other side, I saw how often EMs want to take on work that is exciting, but adds no real value. Especially if the PM is the one to propose it!
A PM once proposed building a risk evaluation system to handle a very specific part of a flow. The idea was presented with a polished mockup and a well-written user stories - it looked great and, from an engineering standpoint, was very appealing since it was very different from our usual work.
Even though I was tempted, my response was to acknowledge the quality of the proposal while clarifying that it was outside the scope of our team. I believe that teams exist to solve specific problems within their domain. Taking on work outside that scope - even if it looks exciting - can hurt focus and impact.
The most unfair thing we can do to a team is to assign work that looks interesting but delivers little to no real value.
What I enjoyed reading this week
Retention: The situationship of SaaS (on churn in the AI era) by
.Being too ambitious is a clever form of self-sabotage by
. A truly beautiful piece, resonated a lot with me.We Tried That - Past results are not indicative of future results (on why your org should try again) by
Coming with the history of doing almost anything around the product development lifecycle (development, testing, product management, project management, customer support, all in both hands-on and management roles; and my only gap being design), I support it wholeheartedly.
As a matter of fact, I often quote my spell at customer support. Dealing with the most difficult cases of pissed off customers is an experience that opens eyes for an entirely different point of view.
But each of my vantage points helped me many times, as it enables easy empathizing with all the roles involved in building a product, either as a leader or a stakeholder.
Curiously, I expect this kind of more holistic perception of engineering work is what we have in the cards. Software development jobs evolve away from narrow specialization, which has been a constant trend for more than two decades already. And if anything, I think it's a good change.
As customers and users, we will appreciate the new reality where product developers have to have broader perspectives themselves, and don't just count on other folks in product ownership, design (heck, back-end, front-end, devops, too) roles.
Thanks a lot Anton for the opportunity!