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.