Sep 1, 2023 · 5 min read
We've all been there. You're working on a product, maybe something complex. You know what problems customers have, the team is smart, but getting impactful features out the door feels like wading through mud. Progress stalls, and everyone gets frustrated.
Often, the issue isn't just the technical complexity. It's how we structure the work between Product Management and Engineering. The traditional model, where PMs gather requirements, write detailed specs, and "hand them over" to engineers, can become a major bottleneck.
In many companies, the PM role looks something like this: talk to sales/customers, write a big document defining a feature, maybe get sign-offs, then tell engineering what to build. Engineers are often "shielded" from the messy details of business goals or direct customer feedback.
This might seem efficient ("let engineers code!"), but I've seen it backfire:
This model breaks down fast. You can't effectively spec out every detail of a feature or a complex integration without deep technical understanding.
Who knows the capabilities, limitations, and potential of your complex system better than the engineers building and maintaining it every day?
When we built features at Juro, some of our best breakthroughs came not from a detailed spec, but from an engineer understanding a technical possibility or seeing a pattern across customer issues that a non-engineer might miss. They understand the trade-offs, the performance implications of different approaches, and the most direct way to solve a technical challenge.
Forcing them to just implement a pre-defined spec often means missing out on simpler, faster, or more powerful solutions. If we want to build great technical products quickly, we need to let the people who understand the technology best make more of the decisions about how we solve problems.
So, if engineers are driving more product decisions, what do PMs do? They shift from being controllers to being enablers. Their crucial job is to provide the context – the map and compass – that engineers need to make good product decisions.
This means PMs need to get really good at:
The PM's role becomes less about defining the solution and more about deeply understanding and clearly articulating the problem, the user, and the business context. They challenge assumptions and ask hard questions, ensuring the team is heading in the right direction, but they trust engineers to chart the best technical course.
Giving engineers autonomy doesn't mean chaos. It means replacing slow, bureaucratic approval processes with faster, more effective feedback loops.
This creates accountability based on results, not on checking boxes in a process document.
How can we apply speed-focused ideas from fast-moving tech companies to the often more constrained B2B world?
Building complex products faster often requires rethinking the traditional PM/Eng dynamic. It means trusting engineers with more product decisions because they understand the technical realities best. It means redefining the PM role to focus intensely on providing the deep business, customer, and market context engineers need to make informed decisions. And it means building accountability through fast feedback loops focused on actual outcomes, not rigid processes.
This shift isn't easy. It requires trust, clear communication, and a willingness to let go of old control structures. But empowering engineers with the right context is often the key to unlocking greater speed and building better, more innovative products.