Frameworks Notes from the Jagged Frontier
Product Management Operating Model Enterprise AI

Product Health Diagnostic

Field framework · For CPOs and product leaders assessing their own organization

Most product organizations know something is wrong before they can name what it is. Features ship and flatline. Adoption stalls after launch. Engineers are busy but the roadmap is not moving the business. The team is building but the outcomes aren't compounding.

The instinct is usually to fix the symptoms: run more discovery, add more process, hire a stronger PM. But most product health problems are systemic. They sit inside the operating model — how the organization decides what to build, how it allocates resources, how it learns from what ships.

This diagnostic is designed for a CPO or product leader who suspects the system is broken but can't name where. It surfaces the root cause across five failure points and tells you where to focus first. It is not a checklist. The questions are designed to reveal structure — and the structure reveals what to fix.

The product system has five failure points: what you decide to build, what you fund and kill, how well you build it, whether it lands in the real world, and whether you learn from what happens after it ships. A weakness in any one compounds the others. A broken discovery process produces a broken roadmap. A broken roadmap overloads engineering. Overloaded engineering produces fragile builds. Fragile builds stall adoption. Stalled adoption produces the wrong intelligence for the next cycle.

How to use this framework. Start with the triage. Five questions — one per section. Any yes tells you where the most acute failure is. If multiple sections are failing, start with Strategy and Discovery: the upstream problem almost always feeds the downstream ones. Once you have a starting section, work through its five root cause questions. Each question points to a different fix. A yes on prioritization discipline calls for a different intervention than a yes on strategic alignment, even though both live inside the same section.

The output of the diagnostic is not a scorecard. It is a hypothesis about where the system is breaking and what lever will actually move it. That hypothesis leads to either a process and operating model fix or an AI automation opportunity — and knowing which one to pursue first is what separates useful diagnostics from expensive ones.

Triage

Where to start

Five questions. Each points to a section. Any yes is a starting point. Multiple failures: start with Strategy and Discovery.

Strategy and Discovery
Are PMs building features customers rarely use, or struggling to explain why a priority is a priority?
Yes → start with Strategy
Portfolio and Investment
Are resources spread across too many initiatives with no clear prioritization logic?
Yes → start with Portfolio
Build, Velocity and Tech Debt
Is delivery slowing down, or are the same production issues surfacing repeatedly?
Yes → start with Build
Validation and Adoption
Is the product solving the problem it was built for when customers use it in their real environment, or is adoption stalling after launch?
Yes → start with Validation
Product Intelligence
Do you know who your most important customers are, how they use your product, and whether they are actually getting value from it?
No → start with Product Intelligence
Section 1 through 5

Diagnostic sections

Each section has five root causes. Each root cause has one diagnostic question. The question is not the full picture — it is the entry point. When a question surfaces a yes, the job is to understand why. The why is what determines the fix.

Strategy and Discovery

Building the right things
  • Customer insight Are priorities grounded in direct observation of customer workflows, or inferred from calls and support tickets?
  • Problem definition Is the problem defined clearly enough that engineering, design, and leadership would describe it the same way?
  • Customer outcome linkage Is the roadmap tied to specific customer outcomes — adoption, time to value, retention — or is it a list of features tied to business metrics only?
  • Prioritization discipline Are priorities set from evidence, or from the loudest stakeholder?
  • Strategic alignment Does the product roadmap connect to the company's one-year business strategy, or does it operate independently?
Revenue impact
Better discovery raises feature adoption on the same engineering spend. Fewer wasted builds. Faster time to value for new customers.

Portfolio and Investment

Focus and capital allocation
  • Prioritization clarity Is there a shared framework for how investment decisions are made across product, engineering, sales, and infrastructure, or does allocation happen by default?
  • Portfolio balance Is investment across new and existing products, markets, and customer segments intentional, or does it drift based on short-term sales pressure and infrastructure constraints?
  • Build vs buy vs partner Is the make or integrate decision made explicitly with clear criteria, or does it default to building?
  • Financial visibility Does leadership know the revenue, cost contribution, and gross margin of each product well enough to make real trade-offs — including where discounts are eroding margin?
  • Kill discipline Are underperforming or strategically irrelevant products stopped, or do they persist because no one makes the call?
Revenue impact
Engineering capacity redirected from zombie products to high-value bets. Build vs buy decisions that do not create long-term liability.

Build, Velocity and Tech Debt

Building things well
  • Capacity allocation What share of engineering capacity goes to new value versus maintaining and fixing what exists — and is that ratio intentional, including its cost-to-serve implications?
  • Tech debt visibility Is tech debt tracked formally with a clear owner, or discovered reactively when something breaks in production?
  • Delivery predictability Is cycle time improving or worsening, and does the team know why?
  • Definition of done Do product and engineering share a clear, consistent definition of done, or does it vary by team and sprint?
  • Execution patterns Are recurring build failures affecting customer commitments and SLA obligations, or is each incident contained?
Revenue impact
More shipped value per engineer. Recurring build failures erode customer trust and trigger SLA penalties. Tech debt that goes unaddressed becomes the ceiling for growth, compressing engineering capacity and delaying market windows.

Validation and Adoption

Did it land in the real world
  • Pain point resolution When the product reaches the real world, does it solve the specific problem the customer bought it to solve?
  • Value messaging Is the value proposition clear and resonating with the right buyer, or are customers starting with misaligned expectations?
  • Functional completeness Are features working as designed in production conditions, or do gaps emerge after implementation that weren't visible earlier?
  • Non-functional barriers Are performance, reliability, or integration issues blocking adoption even when the functional problem is solved?
  • Time to value Are customers reaching meaningful usage and realizing the promised outcome within a defined window?
Revenue impact
Higher production conversion. Faster time to value reduces churn risk in the first 90 days. Removing non-functional barriers unlocks expansion in accounts where adoption has stalled.

Product Intelligence

Using customer and product data to make better decisions
  • Customer feedback Do customers have sufficient platforms and forums to surface needs and signal value — community, advisory boards, support, research, NPS — or is feedback arriving informally and inconsistently?
  • Sales and expansion intelligence Is usage telemetry surfacing signals that tell sales and CS when a customer is ready to expand, at risk, or underutilizing value?
  • Product decision quality Are roadmap priorities and portfolio investment decisions made from customer patterns and usage data, or from instinct and stakeholder pressure?
  • New opportunity identification Are customer usage patterns and conversations surfacing new segments, use cases, or partnership opportunities?
  • Pricing intelligence Are pricing and discount patterns surfacing signals about product value perception — where customers push back, where they pay full price, and what that tells you about packaging and positioning?
Revenue impact
Product decisions grounded in real usage patterns rather than loudest stakeholder. Expansion signals surface before CS misses the window. Pricing intelligence informs packaging decisions that improve gross margin without losing customers.
From diagnostic to action

Choosing the right lever

Each section's root cause questions point to one of two kinds of fixes: a process, people, or operating model intervention — or an AI automation opportunity. Knowing which one applies is the most important decision in the diagnostic, and it is the one most frequently skipped.

The most common mistake is reaching for automation before the underlying process is clean. An AI app built on a broken workflow does not fix the workflow — it executes the broken workflow faster and at scale. The classic example: a team builds a deal risk monitor to surface stalled deals, only to find that reps don't act on the alerts because their incentives are tied to new pipeline, not conversion. The tool is working. The process is broken. The problem gets worse, not better.

The diagnostic is designed to surface this distinction. Ask one question first: is the root cause a signal gap or a behavior gap? A signal gap means the team lacks the information to act correctly — they would do the right thing if they could see it. That is an AI automation candidate. A behavior gap means the team has the information but is not acting on it — because of incentives, habits, unclear ownership, or broken process. That requires a process fix first, regardless of what the AI can do.

If the same problem appears across multiple sections of this diagnostic, check incentives before anything else. Misaligned incentives produce consistent symptoms across the entire product system — weak discovery, zombie products, slow builds, stalled adoption, and blind spots in the intelligence layer all at once.

Fix the process first. An AI app built on a broken workflow produces broken outputs faster. When the root cause is a signal gap and the process is clean — apply the Go/No-Go filter before building.

The Go/No-Go filter

Before you build an AI app

Not every diagnostic finding warrants an AI solution. The Go/No-Go filter is a four-gate test. An automation idea must pass all four gates before it earns engineering resources. Fail any one and the honest answer is: fix the underlying condition first.

Gate 1 — Does the workflow already work without AI? If the current process is broken, adding AI automates dysfunction. The output of a well-designed AI app is only as good as the process it runs on. Before asking what AI can do, ask whether the manual version of this workflow produces the right outcome when done well.

Gate 2 — Is the ROI defensible? Can you articulate the value clearly enough that a CFO would approve it — in terms of cost reduction, revenue acceleration, or risk mitigation? If the business case is vague, the app will be built to a vague standard and measured against nothing. A clear ROI hypothesis is the forcing function for a clear product definition.

Gate 3 — Is the data clean enough? AI systems are only as reliable as the data they run on. If product telemetry is incomplete, CRM data is inconsistently logged, or customer signals are scattered across disconnected systems, the app will produce unreliable outputs. Data quality is the constraint that most teams underestimate and most post-mortems cite.

Gate 4 — Can you measure success objectively? If you cannot define what "working" looks like with a clear metric and a time horizon, you cannot evaluate whether the app is delivering value — or whether it has quietly drifted from its purpose. Every AI app should ship with a defined business metric and a review cadence.

Fail any gate: stop and fix the underlying condition. Pass all four: proceed to scope the app against the specific root cause the diagnostic identified.

Product AI apps

Five automation opportunities across the product system

These five apps map directly to the diagnostic sections. Each addresses a specific signal gap — not a behavior gap. Each assumes the process is clean and the data gate has passed.

Feature adoption intelligence (Strategy and Discovery). Correlates feature usage with retention and expansion signals to surface which capabilities actually drive customer outcomes — and which are being built to a pattern of waste. The app is not a feature tracker. It is a signal that tells the PM team where discovery assumptions were wrong and where they were right, closing the loop between what was promised in the roadmap and what customers actually do after launch.

Portfolio health monitor (Portfolio and Investment). Tracks revenue and cost contribution by product line against strategic investment intent, flagging where the portfolio has drifted from plan. The app surfaces zombie products before they consume another quarter of engineering capacity, and identifies where the build vs buy decision has created long-term liability rather than leverage.

Engineering capacity and debt tracker (Build, Velocity and Tech Debt). Models the ratio of new value delivery to maintenance and debt service in real time, connecting technical decisions to financial outcomes. When capacity allocation drifts toward debt, the app flags it before it becomes the ceiling for the next product cycle. Built on engineering telemetry, CI/CD data, and incident history.

Production adoption tracker (Validation and Adoption). Monitors the journey from feature launch to realized customer value — time to activation, functional gaps surfaced post-launch, non-functional barriers by customer segment. The app distinguishes between adoption problems caused by product gaps and adoption problems caused by change management or messaging failures, pointing to the right fix rather than the nearest fix.

Customer and market intelligence engine (Product Intelligence). Aggregates signals across usage telemetry, support patterns, NPS, expansion data, and pricing behavior into a single intelligence layer. Surfaces expansion-ready accounts before CS misses the window, identifies emerging use cases before a competitor does, and connects pricing signal to packaging decisions that improve gross margin without churning existing customers.