Why Is Building Stuff Sometimes So Slow?
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.
PM as Gatekeeper
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:
- Lost Nuance: Engineers get a filtered view, missing crucial context about the why behind a feature or the real user pain point.
- Technical Disconnect: PMs, often less technical, might define solutions that are awkward or overly complex to build, not leveraging the engineers' knowledge of what's actually feasible or elegant.
- Slow Decisions: PMs become the bottleneck for every question or clarification, slowing down development.
- Frustrated Teams: Engineers feel like ticket-takers, not problem-solvers. PMs feel like they're just managing a backlog.
This model breaks down fast. You can't effectively spec out every detail of a feature or a complex integration without deep technical understanding.
Engineers Understand the Engine Best
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 we solve problems.