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 how we solve problems.
Provide the Map and Compass
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:
- Deep User Understanding: Going beyond feature requests to truly understand the user's JTBD, their workflow, and their biggest pain points. (Engineers should talk to users too!)
- Market & Competitor Awareness: Understanding the landscape, where the market is going, and what competitors are doing.
- Business Context: Clearly communicating the company's goals, target markets, and key business metrics. How does this feature help us win?
- Data Analysis: Digging into product analytics to understand how features are actually being used (or not used) and identifying opportunities or problems.
- Synthesizing Feedback: Gathering input from Sales, Support, and customers and distilling it into clear themes and problem statements, not just feature lists.
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.
Staying Aligned
Giving engineers autonomy doesn't mean chaos. It means replacing slow, bureaucratic approval processes with faster, more effective feedback loops.
- Clear Goals: Instead of feature lists dictated by PMs, maybe teams set outcome-oriented goals each quarter (e.g., "Improve reliability of the voice channel," "Reduce onboarding time for new HR bot"). Engineers decide what to build to hit those goals.
- Transparency: Make work visible. Use shared roadmaps (maybe Now/Next/Later style), open sprint notes, accessible analytics. Let people pull the information they need.
- Regular Outcome Reviews: Have structured check-ins (maybe monthly) where the team (Eng + PM + maybe leadership) reviews the impact of what was shipped. Did usage go up? Did support tickets go down? Did key customers adopt it? Use data and customer feedback to assess if the decisions made are moving the needle. The team lead (often an engineer) then decides whether to stay the course or adjust.
This creates accountability based on results, not on checking boxes in a process document.
Moving Faster
How can we apply speed-focused ideas from fast-moving tech companies to the often more constrained B2B world?
- Less Design Dependency (Not Zero): Maybe engineers build the first functional version using a design system, getting core logic working before intensive design polish. Iterate on design based on working software, not static mocks.
- Radical Transparency: While you can't always share everything publicly, be radically transparent internally. Open roadmaps, accessible data, shared customer feedback – break down internal silos.
- Small, Empowered Teams: Keep teams small (ideally 3-6 people) with a clear mission and an engineer leading. Let them own a problem end-to-end. Split teams when they get too big. This increases ownership and reduces communication overhead.
Conclusion
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.