Product Management in 2027: When Building Is Cheap and Knowing Is Not

The code was done on a Tuesday. The decision wasn't done for three weeks.

The spec was clear. A coding agent had it running by the afternoon, tests included, behind a flag. Then it waited for certainty: was this the thing customers actually needed, or the thing that had been mentioned loudest in the last customer sync? Nobody could say with evidence, so we did what product teams do and scheduled a conversation about it.

Four hours to build, three weeks to be sure. If you want to know what product management looks like in 2027, start with that ratio and follow it to the end.

The bottleneck moved, and the org chart didn't notice

For twenty years, product management was organized around a single scarcity: engineering time. Everything we call "the product process" is machinery for rationing it. Roadmaps decide what the scarce resource works on next. Backlogs queue for it. Prioritization frameworks exist so that two PMs arguing for the same engineers have a civilized way to lose. Even discovery was shaped by the scarcity: you did just enough of it to avoid wasting a sprint.

That scarcity is dissolving. A coding agent with a clear spec builds in hours what took a sprint, and I've watched a two-person team ship what used to need a squad. It isn't just my team. In McKinsey's State of AI 2026 survey, 32 percent of organizations said they had decided against buying at least one software product or feature because they could build it internally with coding agents. Build capacity stopped being the thing you buy.

A constraint doesn't disappear when you remove it, though. It moves, and the data already shows the first leg of that move. McKinsey's Technology Trends Outlook 2026 cites a study in which AI tools raised coding activity by 180 percent while shipped releases rose by only 30. Just a quarter of companies using agentic development tools report any meaningful acceleration of their product cycle. A Harvard working paper by Fiona Chen and James Stratton, built on data from 718 firms and roughly 726,000 workers, finds the same shape: agent adoption raised commits by 20 percent and lines of code by 30 percent, but the gains only partially reached finished output, because review times grew. The bottleneck had moved one step downstream of the code.

It won't stop there. Review is a bottleneck you can engineer around with better evals and with agents reviewing agents. The one you can't engineer around with more code sits further upstream, at the part of the cycle nobody ever systematized because it was never the slow part: the beginning. Finding the right signal, with enough context to act on it. Getting feedback from the customers who matter before the build rather than after.

This is where most product organizations are still manual. The signals live in six systems that don't talk to each other, from the support desk and usage analytics to the CRM, recorded sales calls, app-store reviews and churn interviews. A human reads some of them, remembers a fraction, and carries that fraction into a meeting where it competes with whoever argues best. We call this discovery. It's closer to sampling with a leaky bucket.

When building is cheap and knowing is expensive, the product function inverts. The job is no longer deciding what the engineers do. The job is engineering the system that knows.

What the front end looks like when it's engineered, not scheduled

I've started calling the end state AI Forward Engineering: a product loop that runs forward by default, where the front end of signal, synthesis and decision is automated the way the build step already is, and where humans intervene by exception rather than by routine. By 2027, I expect it to look like this.

Discovery is wired, not gathered. Every source that holds customer truth is connected: tickets, telemetry, transcripts, renewals, feature usage per account. Agents read all of it continuously and attach evidence to every cluster they find. What arrives is a ranked list of candidate problems with the receipts attached, refreshed every morning, rather than a dashboard someone has to interpret.

Ideation is generated, then filtered. Today a PM's ideas come from their own head, their last few customer calls and whatever a competitor shipped. In the loop, agents generate the hypothesis space, ten ways to address a cluster with a cost estimate and a predicted effect on the signal for each, and a written policy filters it. The PM curates a portfolio of hypotheses instead of inventing them one at a time.

Feedback is per account, and it arrives in days. The build ships behind a flag to the accounts that produced the signal. The loop measures whether the signal went away, in fewer tickets, changed usage or a renewal that stopped being at risk. If it didn't, the hypothesis was wrong and the next one ships.

Decisions are policy, not meetings. The PM stops deciding individual features and starts writing the rules under which features get decided. What ships automatically: a UI fix requested by more than three percent of active accounts, no data-model change, behind a flag. What needs a human: anything touching pricing, permissions or a workflow a regulator cares about. What never ships without a conversation: anything a top-ten account has said they don't want. Thresholds, guardrails, kill criteria. A versioned policy file, reviewed every week and enforced all the time.

The PM's week, rewritten. No sprint planning, no prioritization meeting, no roadmap deck. Instead there is a weekly policy review, an exceptions queue and the evals, meaning the tests that tell you whether the loop is still making good calls. The conversations with customers don't go away. They get reserved for the five percent of cases the loop can't settle, which are exactly the conversations worth a PM's time.

None of this is the default yet. Gartner's 2026 Hype Cycle for Agentic AI puts organizations that have actually deployed agents at 17 percent, with more than 60 percent planning to within two years. The wiring is mostly still ahead of us.

I run a small version of this today, on my own writing. A research scan runs every week and analytics are pulled every Thursday; the next piece is chosen from what the numbers say about hooks, formats and topics rather than from what I feel like writing. Twenty-one posts in, the loop works, and it has overruled my instincts more often than I'd like to admit. It's a toy next to a product organization, but it's the same shape. The bigger version is what I'm building toward at Rapid Next, for 1,800 customers whose signals currently arrive through exactly the six-week path above.

What it changes about the product

Follow the loop to its end and the definition of "a product" changes. If discovery reads signals per account and building is cheap enough to act per account, nothing forces one version of the software on everyone. A funeral home with two locations and a crematorium operator with twelve don't need the same workflow; they've just never been able to afford different ones. In a forward-running loop, individualization isn't a premium feature. It's the default output.

If you run a product organization, time your last three features from the first customer signal to the shipped flag, and look at where the weeks went. Your engineers already got faster. The question is whether your discovery did.

Sources

• McKinsey, Technology Trends Outlook 2026 (September 2026). mckinsey.com
• McKinsey, The State of AI 2026 (August 2026). mckinsey.com
• Fiona Chen and James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production, Harvard working paper (2026). stratton.scholars.harvard.edu
• Gartner, Hype Cycle for Agentic AI 2026. gartner.com