Stability

Stability is the phase after shipping where the product either becomes durable or starts leaking value. This phase is about customer health, operational discipline, reliability, and measured improvement. The goal is not just to grow. The goal is to make sure growth is happening on something solid.

Overview

The Overview tab is the operating summary for the phase. It should tell you whether customers are healthy, what is breaking, what feedback is repeating, and what the founder should fix next.

Key signals:

• Stability readiness: A directional rollup of how healthy and manageable the business looks post-launch.
• Metric trends: Whether activation, retention, conversion, and revenue are improving or weakening.
• Customer risk watch: Accounts or users showing churn or renewal risk.
• Reliability watch: Open issues or incidents that threaten customer trust.
• Recurring feedback: The themes showing up repeatedly in support or customer evidence.
• Founder action list: What deserves attention next across product, operations, and customer health.

Why it matters:

• Post-launch chaos can create the illusion of momentum.
• Overview helps you see whether the business is actually becoming healthier, not just busier.

Tips:

• Use overview to spot patterns, then click into the underlying tabs for the real detail.
• If stability readiness feels off, check whether metrics, incidents, and customer health are telling the same story.
• Review this tab on a weekly rhythm, not only when something breaks.

Experiments

Experiments in Stability should be tied to real post-launch metrics such as activation, retention, conversion, support load, or revenue. This tab is for structured learning after launch, not random tweaks.

Key fields:

• Hypothesis: What you believe will improve.
• Channel: Where the experiment runs or where the change is applied.
• Action: What you are actually changing.
• Result: What happened.
• Next action: What you plan to do after reviewing the result.
• Status: Planned, running, complete, or paused.
• Primary metric: The main number the experiment is meant to influence.
• Target value: What success would look like.
• Actual value: What actually happened.
• Audience: Which users or segment the experiment affected.
• Owner: Who is responsible for it.
• Decision: The conclusion after reviewing the evidence.
• Linked metrics: Metric entries that show the outcome numerically.
• Linked issues: Product or support problems related to the experiment.

Why it matters:

• Post-launch teams often make changes without defining what success means.
• This tab helps turn iteration into measurable learning instead of reactive tinkering.

Tips:

• Keep experiments tied to one clear metric when possible.
• Record decisions explicitly so the result changes future behavior.
• If the result is mixed, capture why before moving on.

Customer Health

Customer health tracking captures churn risk, renewal notes, retention signals, and expansion signals so the business can respond before users disappear.

Key fields:

• Customer name: The account or user being tracked.
• Segment: The group they belong to.
• Plan: Their current pricing plan or package.
• Health score: Directional view of how healthy the relationship is.
• Status: Healthy, at risk, churned, expanding, or another current state.
• Last touchpoint: Most recent meaningful interaction.
• Renewal date: When the next contract or decision point happens.
• Retention signal: Evidence that the customer is likely to stay.
• Churn reason: Why they may leave or already left.
• Expansion signal: Evidence of upsell, seat growth, or stronger usage.
• Next action: What needs to happen next.
• Notes: Additional context that matters.

Why it matters:

• Retention problems often show up before churn does.
• A simple health system helps founders act before the account is already gone.

Tips:

• Health scores are directional, not mathematical truth.
• Focus on real signals such as usage, touchpoints, support patterns, and renewal risk.
• Expansion signals are valuable too. Stability is not only about preventing loss.

Issues and Support

Issues track recurring complaints, bugs, friction, billing pain, and feature requests. This tab is where customer pain becomes a prioritizable queue instead of scattered anecdotes.

Key fields:

• Title: The issue name.
• Type: Bug, support, usability, billing, or request.
• Severity: How damaging it is when it occurs.
• Frequency: How often it happens.
• Status: Open, in progress, resolved, or similar.
• Affected segment: Which users or customers are impacted.
• Workaround: What people can do until the issue is fixed.
• Linked metrics: Metrics affected by the issue.
• Linked experiments: Tests or changes tied to fixing or understanding the issue.
• Notes: Additional details or context.

Why it matters:

• A low-severity issue that happens constantly can be more dangerous than a rare severe bug.
• This tab helps you prioritize based on customer impact, not just engineering interest.

Tips:

• Track frequency honestly. Repetition is one of the strongest signals here.
• Use affected segment to separate isolated edge cases from broad customer pain.
• If there is a workaround, write it clearly enough that support can actually use it.

Incidents

Incident logging helps you record what broke, how severe it was, how it was resolved, and what should prevent a repeat. This turns outages and failures into structured learning.

Key fields:

• Title: Short description of the incident.
• Status: Open, monitoring, resolved, or similar state.
• Impact: Low, medium, or high severity.
• Started at: When the incident began.
• Resolved at: When it was fixed or stabilized.
• Summary: What happened in plain language.
• Root cause: Why it happened.
• Prevention: What should stop this class of failure from happening again.
• Affected customers: Who was impacted.

Why it matters:

• Teams that do not log incidents usually repeat the same preventable failures.
• This tab improves reliability and makes operational risk visible over time.

Tips:

• Write the summary so a non-engineer can still understand the business impact.
• Root cause should describe the real failure mechanism, not just the symptom.
• Prevention is the most important field after resolution.

Metrics

Metrics are where post-launch health becomes visible numerically. Track topline numbers, but also track channel, plan, cohort, or segment cuts where possible so the business is easier to understand.

Key fields:

• Week start: The reporting period.
• Activation: How many users reached the meaningful first value point.
• Retention: How many users stayed active or came back.
• Conversion: How many people moved to the next commercial step.
• Revenue: The topline business output for the period.
• Notes: Important explanation for anomalies or context.
• Segment: The user segment being measured.
• Channel: The acquisition source being measured.
• Plan: The pricing plan or tier being measured.
• Cohort label: The cohort or group name if applicable.
• Is cohort: Whether the entry is specifically cohort-based.

Why it matters:

• Aggregate numbers often hide where the real problem is.
• Segmented metrics help you tell whether the issue is audience, channel, pricing, onboarding, or retention.

Tips:

• Notes matter more than people expect when reviewing trends later.
• Keep definitions consistent so your time series stays comparable.
• If a metric moves sharply, capture likely explanations while the context is fresh.

Feedback Library

The feedback library is where qualitative customer evidence becomes a reusable operating asset. It helps you capture complaints, requests, praise, objections, and churn reasons in one place.

Key fields:

• Type: Complaint, request, praise, objection, churn reason, or similar category.
• Source: Where the feedback came from.
• Summary: The key point being communicated.
• Customer segment: Who the feedback came from.
• Frequency: How often the same theme appears.
• Linked issue: Product or support issue connected to the feedback.

Why it matters:

• Repeated qualitative signals often explain metrics before the numbers make it obvious.
• This tab keeps customer voice connected to product and operational decisions.

Tips:

• Frequency is one of the most useful fields here.
• Try to preserve the essence of the customer language instead of over-polishing it.
• Link recurring feedback to real issues when possible so follow-up becomes easier.

Runbooks

Runbooks reduce chaos. Capture repeatable support, release, incident, billing, and ops workflows before you desperately need them.

Key fields:

• Title: Name of the runbook.
• Category: Support, release, incident, billing, operations, or another operating area.
• Trigger: The condition or event that should cause someone to use the runbook.
• Steps: The ordered actions to take.
• Owner: Who maintains or owns the workflow.
• Status: Draft, active, or outdated.

Why it matters:

• Stability breaks down when critical processes depend on improvisation.
• Runbooks help a solo founder or small team respond consistently under pressure.

Tips:

• Keep steps specific enough to be executable.
• Update runbooks after real incidents or support patterns change.
• If a workflow is used repeatedly, it probably deserves a runbook.

Check-ins

Check-ins are the weekly reflection rhythm for the business. They help you record what improved, what blocked progress, and what deserves focus next.

Key fields:

• Week of: The week being reviewed.
• Wins: Meaningful progress or positive signal from the week.
• Blockers: What slowed or stopped progress.
• Next focus: The most important priority for the upcoming week.

Why it matters:

• Weeks disappear quickly after launch.
• Check-ins create continuity and help you notice whether the business is compounding or simply reacting.

Tips:

• Keep wins concrete, not inspirational.
• Blockers are only useful if they name the real constraint.
• The next focus should usually be short enough to influence the next seven days directly.

Phase Gate Checklist

The Phase Gate Checklist appears on the Stability overview and evaluates whether the project is ready to advance to Expansion. Gates check whether key Stability activities have been completed - metrics tracked, customer health monitored, incidents documented, feedback captured, and runbooks written.

Phase gates are advisory, not blocking. They highlight what is strong and what is still weak so you can make an informed decision about advancing. If a gate is not met but you have good reason to proceed, you can override it and the decision is recorded.

Tips:

• Review the checklist before requesting a phase change. It tells you exactly what the system considers ready vs. incomplete.
• Stability gates focus on operational readiness for scale. Advancing without incident documentation or runbooks means scaling without a safety net.
• A product with strong metrics but no feedback library may be ready to grow but blind to emerging customer pain.

Health Scorecard

The Health Scorecard shows a composite health score for the project across five dimensions: Clarity, Proof, Construction, Stability, and Expansion. Since the project is in the Stability phase, the Stability dimension is weighted at 50% of the composite score.

The score is calculated from 26 weighted boolean items across all dimensions. Each dimension shows its own score with an expandable checklist of individual items so you can see exactly what is contributing to or dragging down the score.

Tips:

• Focus on Stability items first - they carry the most weight while the project is in this phase.
• A strong composite score with a weak Stability dimension means the earlier phases were solid but the post-launch work is lagging.
• Use the expandable item checklists to find specific gaps rather than reacting to the composite number alone.