Developers must become mini-PMs

Facilitating the shift

When our new CEO started, we talked a lot about how to level up the engineering team. He did his research: talked with fellow CEOs and other leaders about what actually made the difference in their companies. The conclusion was clear. The biggest lever for getting an engineering team to perform on another level is enabling engineers with business context. It was the differentiator that changed companies’ trajectories.

It wasn’t obvious. Every place I worked before had a clear separation: PMs do PM things, developers work on the code. In the best case, developers were brought in to work on solutions for already fully formulated problems, but it was rare.

If you have been working in a software engineering organization for more than a few years, your product management has most likely been organized in one of two ways.

A product manager or a business analyst learns about the domain, gets an idea of how users are supposed to use the product or the feature, and then turns this knowledge into technical requirements. In this case, the product manager is not native to the domain.

The other scenario is that the product manager has a background in the industry the software company operates in and understands what users want firsthand.

In my experience, the second way is better. Working in complex B2B domains benefits tremendously from firsthand knowledge.

In both scenarios, on the other side of the PM, we have a domain-agnostic team of technical experts that gets tickets in and outputs working code.

I’m Roman, CTO at Cambri. I write High-Impact Engineering — a weekly newsletter about how product & engineering orgs work, and break, in their first 30 people. I’ve lived that passage as an executive; now I also advise founders and engineering leaders going through it.

Code was the scarcity

The semi-siloed engineering team was a bad idea to begin with. It just wasn’t that obvious before AI. If a project takes half a year, spending three months on “aligning stakeholders” and “gathering requirements” didn’t seem too bad. The “collaboration tax” of the team going through the PM on every decision was absorbed by slow implementation.

You have probably seen the take that “writing code has never been the bottleneck”. It is not true. It was the slowest and most expensive part of building digital solutions. Pre-AI development processes were built around that scarcity: heavy upfront planning, estimation, tickets with a ton of information. A mistake in defining how a feature works led to very expensive rework; an architectural mistake was a disaster. Not anymore.

Now that the scarcity of writing code has been resolved, we face the real questions, the ones that have been there all along. How are users going to use this? Why is this feature important?

If your developers don’t know the answers to these questions, the upside from writing code faster is limited.

From coders to mini-PMs

Half a year ago I wrote “Let coders code fallacy” about the negative effects of siloing software engineers. I advocated for developers learning the business context and getting ownership over problems rather than only structuring solutions. That is the first-level enabler.

The second-level enabler: teams don’t only need to learn about the problem, they need to be able to make product decisions. Maybe not to change how an entire large feature works, but improving user interactions and addressing corner cases could be done without waiting for a ticket.

What still belongs to PMs: product bets, prioritization, and making decisions when the stakes are higher and there is no obvious best option. This keeps the bigger picture coherent, the parts of the product or a feature fitting together to form a whole that is bigger than the sum of its parts.

On the other hand, smaller design choices, corner cases, error situations, and decisions with several equally good options don’t necessarily need to come from above. As an illustration of this approach in my own work, I encourage developers to use the following steps when encountering a problem or an uncovered case:

• Research it first

• Come up with a solution, or several

• Share them on Slack or as an RFC

• Wait for feedback

• Answer the feedback and adjust the solution if needed

• If there are no objections, create a ticket and go forward with the implementation

In this approach, the developer is not blocked by a PM, who would otherwise be overloaded with making all the decisions, coming up with the solutions, and writing all the tickets. The developer takes more ownership, and the PM has bandwidth for more strategic work.

I don’t believe that product management becomes obsolete. Someone needs to hold the ropes: decide what to do and what not to do. However, “how to do it” is more and more owned by software engineers. Waiting on the PM for every product decision is a bottleneck.

Developers must become mini-PMs.

The direction is clear

Some people will love this, and some will hate it.

I love fast iteration and agency over outcomes. I mourn deep work: sitting with a problem for hours, sometimes days, and the aha moments when confusion and hard thinking turned into clarity.

But the direction is clear. Knowing syntax and a framework is not enough anymore. Most developers must graduate to mini-PMs or become obsolete.

LLMs are getting better and better at turning natural language into code. A fully formulated ticket that just waits to be turned into code is ideal material for an agent. We don’t need as many translators anymore. On the other hand, creators are in high demand.

As managers and leaders, our role is to facilitate this change.

How to get there

I don’t believe in step-by-step playbooks. Do A, then B, then C, and you will achieve my results. If it were true, we wouldn’t have so many failed businesses, burned-out managers, and unhappy, unproductive teams.

However, for what it is worth, I write mostly from my own experience. There are a few things that, if you liked the take in this piece, you can try. They worked for me, and they made my work easier and more enjoyable.

The change starts with context. A developer cannot make a good product call without knowing who uses the product, what they struggle with, and what the business is trying to achieve. Share recordings of product and sales calls, feedback from support, and the real numbers: adoption, churn, won and lost deals. I wrote a playbook for this in “Let coders code”.

Bring engineers in early. A product trio with a PM, a designer, and an engineer, working from the pain point rather than from a ready ticket, plus quick prototypes instead of specification documents. This is the setup that made our big rewrite work.

Formalize your decision boundary. Decide which decisions developers can make and how to communicate them. An example of the process we use is above.

Treat all of this as an experiment: one team, a timebox, a debrief. The same way we change any process.

For fifty years, the industry paid developers to translate. From now on, it will pay them to create. We, as managers, should ease the transition.

P.S. This transition is exactly the kind of work I do with clients. I advise founders and engineering leaders on making their product and engineering orgs perform: shifting decisions to the team, fixing delivery flow, and building the context engineers need. Book an intro call.