Engineering Got Faster. Now the Hard Part is Deciding What to Build.
ferrix
How it works
FAQs
Blog
Start free
ferrix
How it works
FAQs
Blog
Start free
ferrix
Start free
Engineering Got Faster. Now the Hard Part is Deciding What to Build.
Engineering Got Faster. Now the Hard Part is Deciding What to Build.
Nishant Kumar
Mar 17, 2026
The bottleneck in product development is no longer shipping speed. It's the upstream judgment.
Something changed around last December and January. The coding agents crossed a threshold. Features that used to take a quarter now ship in weeks. Instead of walking into a stakeholder review with a slide deck, you walk in with a working prototype.<br>If you’re a product manager, you’ve noticed this change: engineering used to ask, “Can we get more time?” Now it's "what should we build next?" The constraint didn't disappear. It moved upstream to decide what to build.<br>That's product work. And it's where most teams today are least prepared.<br>The Two Layers Of Product Work<br>Some will argue the answer is fewer PMs and more empowered engineers. That's happening at some companies, and in certain contexts, it makes sense. But for most teams, it isn't that simple. They juggle multiple segments, enterprise accounts, and competing priorities from every direction. The real question is: what should you actually be spending your time on?<br>Here's the uncomfortable truth. Most PM work today isn't thinking. It's assembling the context required to think.<br>Consider how you spend a typical week. The work breaks down into two distinct layers, and the split between them reveals the problem.<br>There’s the assembly and execution layer . It gathers signals from support tickets, Slack threads, and analytics dashboards. It also structures plans in documents that few read more than once. Then, it writes specs, files tickets, and tracks whether things ship.<br>Then there's the judgment and steering layer. When you are evaluating whether the signals actually point where you think they do, setting direction when the data is ambiguous, adjusting priorities when a new constraint surfaces, and adding context that no system has because you were in the room when it was said.<br>Most PMs spend the majority of their time on assembly. The shift underway is about reclaiming time for judgment.<br>This isn't a new observation. Every generation of PM tooling has tried to solve it. What's changed is how far the tooling can reach and why each prior wave fell short.<br>How PM Tooling Evolved<br>PM tooling has evolved through three stages, each trying to reduce the same assembly overhead. First, systems organized the work. Then the copilots sped up tasks. Now, agents aim to operate the assembly layer itself.<br>Systems of record<br>Tools like Jira, Linear, Productboard, and Confluence solve the coordination problem. Before them, product work lived in spreadsheets, email threads, and tribal memory. These platforms introduced structured tickets with owners, roadmaps with timelines, documentation with version history, and workflows with accountability.<br>What they didn't solve was the assembly work itself. PMs collect signals from five channels. They feed these into the system. Then, they pull context back out when it's time to make a decision. The system of record holds the output of your thinking. It doesn't help you think.<br>Copilots<br>The Copilot wave includes ChatGPT, Claude, Gemini, Notion AI, and Linear's AI features. They all speed up individual tasks. Need to draft a PRD? Paste your notes, and get a structured spec in minutes. Summarize a long feedback thread? Done. Generate a prioritization framework from a list of competing requests? Quick.<br>But copilots operate on demand, with no persistent context. Every interaction starts from zero. You still collect the inputs, choose what to use, and organize the tasks yourself. The assembly got faster. The operating model didn't change. You're still stitching together signals from Slack. You gather data from your analytics tool. Then, you check what the sales team and GTM team shared last week. Finally, you decide which inputs are important. The copilot helps you write the output. It doesn't help you see the pattern.<br>Agents<br>Agents operate on a completely different premise. Instead of speeding up tasks you initiate, they take ownership of a goal and work across the product cycle to deliver it. They discover signals, prioritize what matters, draft plans, execute on them, and loop back to check whether the work moved the needle. The PM defines the goal and the guardrails. The agent does the rest until a decision requires your input.<br>The hard part is making this reliable across messy, real-world product work. But if it works, the operating model changes. Instead of backlog-driven workflows where you manually triage, prioritize, and assign, the system acts by default. You set direction, define what's off the table, and step in when the agent surfaces a call it can't make on its own.<br>Where Agents Break...