I was listening to Lenny’s podcast with Tom Verrilli recently, and one point resonated above the rest. He said it would be better if engineering and design had enough context to make the exact same product calls a PM would, at least most of the time. He doesn’t take that much further on the podcast, and I want to.

To be clear, this is not PMs versus engineers. Product management is a vital role and we still need it. But most tech orgs have a lot more engineers than they have PMs. So what if more of those builders, or all of them, could make great product decisions, and what if we actually allowed them to?

Why this is possible now

The shift comes down to where builders spend their time. As the coding loops compress, engineers spend less time coding and more time reasoning about what they are actually building. They can polish it. They can make the smaller product calls inside a feature instead of parking them.

And once that is true, your engineers become the DRIs leading the feature end to end. This is not a title change and it is not a reorg. It is what happens when the coding part of the job compresses and the thinking part of the job does not.

What I want from an engineering team

I want a team that is great with systems, makes smart technical calls, and guides agents well as they code. We talk about that part a lot.

The part we talk about less is that I also want a team that knows what a quality product feels like, that can refine and iterate on a feature without heading back to the PM for every micro decision, and that has the intuition to know when a decision genuinely does need to go back. That last one matters as much as the other two. Owning the call includes knowing which calls are not yours.

They lean in because they have real customer context, and not just a quarterly readout.

What we have to fix to get there

If we want engineers making these calls, the org owes them two things.

• Direct access to customers. Real exposure and continuous feedback loops, so their product instincts are built on something.
• A shift in the hiring bar. We need builders who combine technical rigor, an understanding of the customer and the business, and product taste. That combination is rarer than any one of the three, but it is what makes end to end ownership work.

Where PMs fit in

This does not diminish PMs. It scales them.

The expert PMs we have are genuinely expert, and the opportunity is to scale that knowledge rather than spend it one feature at a time. They become a central resource for taste and usability, which are the hardest things to distribute, and that guidance becomes available to every engineer working on a feature and not just the ones who happen to sit on a team with a PM attached.

The other half of it is that this frees them up. When engineers handle the smaller but still impactful product decisions, the PMs get to spend their time on the areas of bigger business change, which is where you actually want your best product thinking going. So it is not taking anything away from them. It moves them to the work only they can do.

Where this leaves us

I think we need to stop treating product decision making as a function that lives in one job title and start treating it as a muscle we want most of the org to have. Give engineers the customer context, give them the taste guidance from the PMs who have it, let them own the feature, and get out of the way. Keep a lightweight demo and product review loop as the guardrail, and let them build.

Most engineers are perfectly capable of making great product calls. In a lot of cases they have just never been given the context or the permission to try.