Product Health Checklist: Is Your Product Secretly Sick?

Revenue is up, but your team is burned out. Stakeholders are mostly happy, but your backlog is a 1,000-item wish list of conflicting demands. Sound familiar?

Welcome to the classic trap: a product that looks healthy on the surface but is rotting from the inside.

We’re obsessed with simple metrics, but true Product Health is not just a number, but a holistic state. It’s the crucial difference between a product that is just surviving and one that is built to win long-term.

This article is a diagnostic guide to the five areas of the Product Health Checklist (PHC 2.0). Let’s see if your product is truly healthy or just good at hiding the symptoms.

Top 6 questions: answer “YES” and your project will be fine

Here’s an amazing insight by Bartek Czarnecki, Pragmatic Coders Product Manager:

I did an analysis of our Product Health Checklist (PHC). As part of that analysis, I looked at the last three years of our weekly Product Sync (PS) meetings. I wanted to check whether there are any questions in the PHC (there are about 50 in total) that are strongly correlated with projects achieving success versus those where things are not going so well.
Below is a list of six questions that have 100% accuracy: they are answered “yes” in projects that are going well (although that does not mean they are free of problems), and “no” in projects that failed, ended prematurely, and so on.
The six questions are:
Is the product strategy driven by the business strategy and contributes to it?
Is the Team engaged in solution validation?
Are milestones (the Roadmap) delivered as planned?
Are there established metrics for assessing product quality?
Are any downtimes/production issues systematically logged and mitigation plans communicated to the Stakeholders?
Is the Product Team encouraged to explore the root causes of problems with the Stakeholders, rather than just delivering predefined solutions?

What the other 19 questions cover (still one checklist)

The six Critical questions above are the strongest signal, but PHC 2.0 still runs the other 19 items—organized in the same five groups as the sheet—so nothing important hides between the cracks.

Strategy & Direction

Beyond the Critical items here, you still check for an outcome-oriented roadmap used in real prioritization decisions, a success metric discussed with the stakeholder, and a vision that both the team and the client can state in plain language.

Example questions:

Is the product strategy aligned with and driven by the client’s business strategy?
Is there an outcome-oriented roadmap built with the client, actively used for prioritization decisions?
Were planned milestones/outcomes delivered in the last 2 sprints (during last month)?

Discovery & Learning

You add evidence on contact with real users or customers in the last four weeks that changed a decision, the biggest current assumption and how you are testing it, and structured analytics that tie releases to observable effects.

Example questions:

Is the team engaged in validating insights and solutions before development starts?
Did we have contact with a real user or customer in the last 4 weeks that influenced a product decision?
Do we know what our biggest current product assumption is, and are we testing it?

Delivery & Quality

You close the loop on sprint goals, backlog readiness and business value ordering, tech debt visible and worked in the backlog, documented rationale for new functionality, and—alongside the Critical quality and incident items—whether delivery stays predictable end to end.

Example questions:

Are sprint goals delivered as planned?
Are product quality metrics defined and monitored?
Are production incidents/downtimes systematically logged with mitigation plans communicated to the client?

Client & Executive Alignment

This group is about the executive layer: recent confirmation of direction from the decision-maker or person paying, the client’s north star for success, value communicated as outcomes (not only a feature list), explicit read on trust and politics, and whether budget or burn rate supports the planned outcomes.

Example questions:

Has the decision-maker/person paying confirmed the current product direction in the last 6 weeks?
Do we know the client’s real north star – what they consider the measure of success for this product?
Does the client understand the value we’ve delivered in the last sprint (outcomes, not just features)?

Team Leadership & Ownership

Here you check whether the product team joins strategy conversations with the client, self-organizes around outcomes and user problems, gets key stakeholders (including whoever pays) into Sprint Review with substantive feedback, and whether that feedback actually moves the backlog.

Example questions:

Does the Product Team participate in strategy discussions both internally and with the client?
Is the team encouraged to dig into the problem cause with the client rather than just delivering the defined solution?
Does the Product Team self-organize its work focusing on outcomes to be delivered and user problems to be solved?

If quality problems show up as nonstop incidents, firefighting, or missed dates, you may need more than a checklist pass. Read Is your project on fire? Self-diagnosis for a deeper symptom review.

Recommended reading: Another good method of finding the source of problems within a project, apart from the above-mentioned checklist, is RCA (Root Cause Analysis). Read more about it in our RCA guide.