You Can't Spec Your Way Out of Uncertainty

“Hey everyone, we’re all here today, reunited to define (I mean, refine) together what’s gonna go on the roadmap for the next quarter. If you please, I’d like each one of you to provide an estimate for all tasks in the backlog that I have prioritized after my thorough analysis that I’ve done in the last 2 months.”

This is what I had to deal with at every single company I joined. The very same companies that defined themselves as “agile.” The ones that believe in “ownership” and “autonomy.” And yet here’s the PM, messenger of the word of stakeholders and customers, asking us developers how much effort something is going to take for the next 4 months.

Agile promised to help teams work with uncertainty. It never made business comfortable with it.

Agile was born to challenge the structured, bureaucratic processes that permeated software engineering up to the 90s (and still do at some companies today). It was the tool that should have helped manage uncertainty in an increasingly complex (if not chaotic) world that was still figuring out the World Wide Web.

The problem is, biz people never liked uncertainty so much (you know, investors, big egos), so agile had to squeeze itself into the cracks between sprints.

Unfortunately for the uncertainty-allergic people, product development has become less predictable since then.

Why Handoff-Based Teams Fail at Uncertainty

Companies responded by splitting the work across specialists: PM handles the “what,” designer handles the “how it looks,” engineer handles the “how it works.” Each domain gets attention, but every stage adds another handoff and another place for context to disappear.

PMs are the bottleneck. In the companies I’ve worked at, PMs juggle multiple initiatives and stakeholders. They become the central node everyone depends on for decisions, context, and prioritization. When one person is spread across five initiatives, four of them are always waiting.

The overhead is real. Three specialised roles means coordination cost. Meetings multiply. Calendars fill with syncs, stand-ups, and alignment sessions. Every decision requires getting three (usually more) people in the same room, or worse, the same Slack thread. The bigger the organization, the worse this gets.

Information dies in transit. Watch what happens when a designer explains a user flow to a developer. Something gets lost. Watch the developer explain technical constraints back to the PM, and more disappears. By the time decisions filter through the telephone game, the original context has been diluted, misunderstood, or forgotten entirely. Handoffs are slow and lossy.

As PostHog’s James Hawkins puts it, engineers end up with “a sanitized version of the truth” and don’t have the right information to make the best decisions.

Chemistry makes or breaks everything. Handoff-based teams depend heavily on people getting along, being open and respectful, and challenging each other without ego getting in the way. When that chemistry doesn’t exist, I’ve seen talented individuals produce mediocre work together because the interpersonal dynamics were off.

Maybe that’s why at times, collaboration sucks (hard).

Local optimization creeps in. Each specialist naturally wants to perfect their domain. The designer obsesses over pixel-perfect interfaces. The developer optimizes for clean code and architecture. The PM builds elaborate roadmaps. Each piece might be excellent in isolation. But product coherence suffers when everyone’s looking at their own slice instead of the whole.

These structures spread uncertainty across more people.

Working With Uncertainty

Traditional teams treat uncertainty as the enemy. They try to eliminate it through planning, documentation, and handoffs: detailed specs, elaborate roadmaps, sign-offs at every stage. The logic seems sound: if we define everything upfront, nothing can go wrong.

Documentation often pushes unresolved uncertainty into implementation, when it becomes expensive to address.

A Product Engineer who owns the full loop, from problem discovery to shipped solution, carries context across the entire process and can respond without waiting for another sync or translating decisions between disciplines.

I started Product Engineers to collect stories, opinions, and the occasional rant about this way of working. Read it at http://productengineers.com, or subscribe if you want this stuff in your inbox.

Masters of Uncertainty

The job of a Product Engineer is to reduce the chance of solving the wrong problem or solving the right one badly.

They start with a business problem such as “enterprise customers are churning” and investigate why before deciding whether the answer is SSO, onboarding, permissions, or something else. The PM brings the business problem, and the PE owns product discovery and solution design.

In practice, this means testing bets before going all-in:

• Assumption testing and experimentation
• MVPs, PoCs, prototypes
• Customer and user conversations
• Concierge tests, Wizard of Oz experiments, and the full Lean Startup toolkit

The goal is to avoid wasting resources on things that might not work.

They own the user experience, from accessibility to interaction design, and they implement it themselves.

Wireframes and code are tools, not the definition of the role. A PE might code a solution from scratch, use a no-code platform, integrate an existing solution, or do whatever solves the problem most efficiently. The focus isn’t “I do product plus design plus engineering” but “I solve product problems, using whatever tools make sense.”

Teams Built for Uncertainty

People who own the full loop can still work together.

Working solo works for some problems, but isolation has costs. When everyone finds problems independently and solves them alone, the product starts diverging. Features feel disconnected, and the overall experience loses coherence.

Small, dynamic teams can form around problems. Kevin Östlin, co-founder of Andsend, calls these “product groups”: two or three people who own a problem together, end-to-end. Watch Kevin explain how product groups work in this episode of the Product Engineers Podcast.

They pair on everything: research, hypotheses, design, implementation, and evaluation. Everyone keeps the full context because they work through each stage together.

These teams form fluidly. Someone identifies a problem worth solving and shares it with the team. Others who find it interesting join. The group tackles it together, ships, measures, then reforms around the next problem.

Traditional teams are permanent. You were assigned to “Team Payments” or “Team Onboarding” and stayed there until someone reorganized. The team’s scope was predefined, the roadmap handed down.

These teams are temporary coalitions formed around problems. The problem determines who joins. Once solved, people disperse and regroup. The org chart becomes fluid, almost irrelevant.

The daily standup becomes a mini planning session. What did you ship yesterday? What hypothesis are you testing today? Who wants to team up on this problem you found?

That conversation provides enough alignment for the day.

Scaling the Model

The model sounds plausible at a startup and fragile at larger companies.

The philosophy still applies at larger companies.

At a startup, a PE might own the entire product. At a larger company, they own a specific domain or problem space. The scope shrinks, but the workflow stays the same. The core unit is the team, a few PEs working on a defined problem space. As the company grows, more teams share the work within a flat management structure.

Product Managers already scale this way. A PM at a startup owns everything; a PM at Google might own how well a button color performs. Both are PMs with different scopes.

The org structure has to evolve too. Companies often call themselves “Agile” while only development teams run sprints and the business keeps handing down long-term feature roadmaps. That’s Agile theater. Product Engineer teams fail under the same conditions when leadership still dictates the features they build.

This model mostly appears in startups and scale-ups today. Established companies with decades of ingrained processes won’t change overnight. Smaller teams that consistently outship them will create pressure to change.

When one aspect of a product requires deep expertise, you bring in specialists. A cybersecurity product needs security experts. A fintech product needs people who understand compliance deeply. Specialists bring deep expertise; PEs own the product work. Specialists and PEs coordinate closely.

Domain experience matters too. A PE who’s worked in banking brings that context to a bank, just as product managers often move between companies in the same industry. A generalist skill set becomes more useful when paired with domain expertise.

Why This Is Happening Now

Product Engineers predate AI. PostHog, Ghost, and Ashby were already using versions of the model before ChatGPT. The work was slower then, especially discovery: prototypes and production code both took longer to build.

AI reduced that friction.

ChatGPT and Copilot have made it easier for engineers to cross language and tooling boundaries. Work once reserved for specialists, such as writing CI scripts or tuning database queries, is more accessible with AI guidance.

For Product Engineers, AI makes navigating uncertainty cheaper. They can spend less time on code mechanics and more on discovery, hypothesis testing, and rapid iteration. Prototypes that took days can take hours, making it cheaper to test an assumption before committing to it. AI can hold context across those steps and support more coherent decisions.

We’re knowledge workers navigating uncertainty. LLMs can hold context, surface patterns, and help us explore possible answers. With strong foundational knowledge, AI becomes a sparring partner for thinking through the work.

One person can now do what required three because the tools caught up.

The Builder’s Mindset

Product Engineers reject fragmentation and embrace the discomfort of not knowing.

Plenty of developers know some design and product thinking. Product Engineers distinguish themselves by how they relate to uncertainty. In a conventional development role, the work starts with clear requirements. Product Engineers are comfortable with uncertainty because building is how they find clarity. They take ownership of product outcomes.

There’s a professional pride at stake. They want to put their name behind great products and take responsibility beyond shipping someone else’s design. They never expected certainty from the spec, so when a feature fails, they ask why they didn’t catch the problem earlier.

Companies hiring this way are betting that fewer people with broader ownership can outperform larger, fragmented teams.

What This Changes

The opening meeting—the PM asking for estimates after the roadmap was already decided—is standard agile theater. Teams will abandon it when a better way of working produces better results.

Plenty of developers already think about product, and plenty of PMs already understand the technical work. The hard part is taking responsibility for the problem early enough to test assumptions and change direction before a roadmap turns uncertainty into sunk cost.