
For Product Managers: Building Under Discovery Compression
For Product Managers: Building Under Discovery Compression
You have a roadmap. It assumes the technological landscape will be roughly stable for 12-18 months. That assumption is breaking.
Discovery compression is not a future phenomenon. It is happening now. The AI capabilities available to your product in Q4 will be meaningfully different from Q2. Your competitors are experiencing the same acceleration. Your users' expectations are recalibrating in real-time.
This is not a strategy document. It is a survival guide.
The Problem You Now Face
Traditional PM planning assumes:
- Technology capabilities are relatively stable
- You can spec features based on current technical constraints
- A 12-month roadmap can be executed as planned
- Your competitive moat comes from sustained execution
Under discovery compression:
- Capabilities change faster than planning cycles
- Specs written today may be obsolete before implementation
- Roadmaps become hypotheses, not commitments
- Moats erode unless they are built on something compression-resistant
The frameworks you learned are not wrong. They are incomplete. They need to be augmented for an environment where the ground moves.
What Actually Changes
1. Your Planning Horizon Compresses
Old model: Annual planning, quarterly adjustments, monthly reviews.
New model: Quarterly planning, monthly replanning, weekly capability scanning.
This is not about working faster. It is about holding plans more loosely. The most dangerous thing you can do is execute a 12-month roadmap without replanning for capability shifts.
Practical move: Build explicit "capability checkpoints" into your roadmap. At each checkpoint, ask: What can we now do that we couldn't when we planned this? What can competitors now do?
2. Build vs. Buy Calculus Flips Frequently
Old model: Build core differentiators, buy commodities. The decision is relatively stable.
New model: What's differentiated today is commoditized tomorrow. Today's core may be tomorrow's commodity.
When AI makes capabilities cheap, your custom-built solution becomes a liability competing against purpose-built tools. When AI shifts, purpose-built tools may lag behind what you could build.
Practical move: Track the "months until commoditized" for every feature you're building. If the answer is less than your build time, reconsider.
3. Your Competitive Intelligence Must Include AI Capabilities
Old model: Watch competitors' products and features.
New model: Watch foundational AI capabilities. Your next competitor may not be a company—it may be a foundation model update that enables anyone to build your product.
GPT-5, Claude 4, Gemini 2—these are not just tools. They are capability discontinuities. When they land, some products become trivially replicable and others become newly possible.
Practical move: Assign someone to track foundation model development. Not for features—for capability plateaus and cliffs.
4. User Expectations Are Recalibrating
Old model: Users compare you to your competitors.
New model: Users compare you to the best AI experience they've had anywhere. ChatGPT, Midjourney, Copilot—these set baselines that bleed across categories.
A user who has experienced AI that just works will not tolerate your legacy search interface. Expectations are not domain-specific anymore.
Practical move: Your baseline is not "better than competitors." It is "doesn't feel broken compared to ChatGPT."

