What PMs Actually Need (vs. What We Keep Building for Them)

PMs don't need:

• more metrics (they're accountable for outcomes, but drowning in numbers that don't inform decisions)
• more workflows
• more feature requests
• more armchair feedback
• more process
• more ideas

PMs need:

• more clarity
• more help expressing ideas
• more understanding of eng capability
• more reasons why an iceboxed feature might work
• more help selling ideas internally
• more alignment to company decision making

Every product ever built for development teams optimizes for the former and not the latter.

Why we keep building the wrong tools

Walk through any product team's stack and you'll find the same pattern: tools that track everything but illuminate nothing.

Dashboards with 47 metrics but zero insight into which ones actually matter. Roadmap tools that beautifully visualize features but can't explain why you're building them. Feedback databases with thousands of requests but no framework for deciding which problems are worth solving.

We built Jira to track work, not to understand it. We built analytics to measure behavior, not to explain it. We built workflow tools to coordinate people, not to amplify their judgment.

The entire category optimizes for visibility over understanding. Process over clarity. Coordination over alignment.

But tool limitations aren't the primary driver of PM dysfunction. The real waste comes from:

• Unclear company strategy forcing PMs to build alignment from scratch on every decision
• Reactive leadership that constantly shifts priorities, invalidating previous work
• Lack of company-wide prioritization creating conflicting demands across functions
• Shifting goals that make yesterday's research obsolete

Tools can't fix these problems. But they can reduce the coordination tax when organizational clarity exists.

What PMs actually do all day

A typical PM day:

• 9:00am: Engineering asks "Should we use Redis or in-memory caching for this?" You have 10 minutes to answer before they make the choice themselves.
• 10:30am: Design presents three mockups. All look good. You need to articulate which one aligns with the product vision you haven't had time to write down.
• 2:00pm: A customer feature request comes in. It's technically feasible but you can't remember if it conflicts with the strategic direction from last quarter's offsite.
• 4:00pm: Your CEO asks why the team is building Feature X instead of Feature Y. You know there was a good reason but the decision context is buried in a Slack thread from six weeks ago.

Every one of these moments requires instant access to judgment, strategy, and context. None of the tools in your stack help with this.

The expression problem

PMs spend half their time trying to express ideas that don't fit into existing tools. You can't put "this feature helps enterprise customers but might confuse prosumers" into a roadmap. You can't capture "we're prioritizing this because our biggest competitor just launched something similar" in a kanban board.

So PMs write docs. Lots of docs. Strategy docs, vision docs, decision docs, context docs. The docs pile up. Nobody reads them. The PM becomes the bottleneck because they're the only person who's read all the docs.

Docs themselves aren't the problem. They enable asynchronous alignment, capture long-term strategy, and create organizational memory. The problem: lack of structured, queryable metadata around those docs. You can't query a Google doc. You can't feed context documents to the AI tools your engineers are using to build features. The reasoning exists but remains inaccessible at decision time.

The alignment gap

PMs are supposed to align everyone around what to build. But alignment requires shared understanding, and shared understanding requires shared context.

When engineering uses AI to implement features, that AI has zero context about:

• Why this feature matters to the business
• What trade-offs are acceptable
• How it fits into the product strategy
• What customer problems it solves

So you get technically perfect features that miss the mark. Beautiful implementations of the wrong solution. Fast execution in the wrong direction.

The tools we've built for PMs don't solve this. They make it worse by adding more process between the PM's judgment and the team's execution.

What better looks like

Tools built for what PMs actually need would:

• Capture product judgment in a format that AI can consume
• Make strategic context instantly accessible when decisions get made
• Help PMs articulate ideas in ways that engineering, design, and business all understand
• Show why an iceboxed feature might work now even though it didn't six months ago
• Connect product decisions to company objectives without forcing everyone into a meeting

Amplifying PM judgment so it can operate at the speed of AI-assisted development: that's the goal. Not replacing PM intuition with automation.

But this requires PMs to evolve new skills. If AI will consume PM judgment, PMs need to understand:

• How to structure reasoning so AI can interpret it accurately
• What patterns of model behavior to expect and how to guide them
• How agents fail and what guardrails prevent common failure modes
• How to design prompts that surface the right context for each decision

AI literacy becomes a core PM competency, not a nice-to-have.

The velocity problem

As AI tools accelerate engineering, the gap widens. Engineers can implement certain features in hours. PMs still need days to build context, align stakeholders, and make decisions. The mismatch creates friction:

• Engineering waits for product direction
• Or engineering moves forward without product input
• Or the PM becomes a bottleneck and gets removed

We've seen all three. None of them work.

But velocity alone creates new risks. Shipping without validation can:

• Erode user trust through misaligned features
• Accelerate technical debt faster than teams can manage it
• Create brand inconsistency across rapidly shipped experiences
• Scale incorrect assumptions before anyone catches them

PMs must actively manage these trade-offs, which is harder when execution outpaces strategic review.

The challenge also varies by company scale. Early-stage startups can compress decision cycles because fewer people need alignment. But mid-market and enterprise companies face unavoidable latency from:

• Compliance review cycles
• Sales commitments already made to customers
• Integration dependencies across multiple teams
• Multi-team coordination requirements

The argument for faster PM output applies most directly to small, agile teams. At scale, many sources of slowness are structural, not individual.

The Future of PM

The product management org of five years from now won't look like the product management org of today.

Less time coordinating between teams through meetings. Less time writing specs that nobody reads. More time encoding judgment into systems that can guide AI-assisted development. More PMs who can make their product thinking accessible when engineers and AI systems need it.

But this doesn't mean eliminating the human work of PM:

• Executive alignment still requires trust built through direct engagement
• Strategic vision still needs articulation that inspires teams
• Cross-functional negotiation still depends on relationship and context
• Long-term product direction still requires human judgment about market evolution

The shift is toward augmenting these activities with better infrastructure for capturing and surfacing the reasoning behind them.

Product leaders of today have the opportunity to shape that evolution. The tools exist to build this future. The question is whether we'll build them for what PMs actually need, or keep optimizing for more metrics, more workflows, and more process.