Goal

Continuing the product engineer career path discussion, this article helps software engineers build a basic product thinking framework:

1. What validation stages does product innovation usually go through?
2. What qualitative judgment should be made at each stage?
3. What quantitative metric can be used to validate that judgment?

This article draws on Lean Analytics, a book on validating innovation that also helps engineers develop product thinking.

Recommended by Kevin Weil, Dan Martell, Fan Bing, Zhang Ximeng, and Ding Lei.

Why

Software engineers often join product work from the delivery side. They know how to build the system, but may not have a clear framework for judging whether the product direction itself is valid.

Common gaps include:

• Not knowing which stage the product is currently in
• Treating all metrics as equally important
• Confusing feature delivery with product progress
• Optimizing technical or operational details before validating the core product risk
• Lacking a shared language for discussing product value, business risk, and user behavior

This article uses Lean Analytics to provide a simple operating framework:

• Use stages to locate the current product uncertainty
• Use qualitative questions to clarify what needs to be judged
• Use quantitative metrics to validate whether the product is moving forward

How

The core process is:

1. Identify the current product stage.
2. Identify the main question of that stage.
3. Choose the evidence that can validate the question.
4. Choose the quantitative metric that best represents the evidence.
5. Use the metric result to decide whether to keep iterating, change direction, or move to the next stage.

Note: The underlying logic draws on On Contradiction (identify the main question at each stage) and On Practice (test judgments through practice). Interested readers can explore both essays in Selected Works of Mao Zedong.

What

This article has four parts:

1. Product Decision Pattern: how to turn product uncertainty into decisions.
2. Metrics: how to choose useful indicators.
3. Stages: how product innovation stages map to main questions, OMTM, focus, pass logic, and examples.
4. Business Model Metric References: stage-based metric references for different business models.

Product Decision Pattern

Use Stage to Choose Metrics

Different stages require different metrics.

The metric should serve the current biggest risk. A product in the empathy stage should not optimize channel ROI. A product with weak retention should not treat paid acquisition as the main problem.

Use Metrics to Decide Actions

Use Stage Signals to Ask for Resources

The stages are introduced in the Stages section below. For product engineers, stage signals are evidence for asking the company to start, continue, or expand a project.

Note: In startup language, these signals are similar to PMF evidence. Founders use PMF evidence to ask investors or partners for more resources; product engineers can use stage evidence to make similar resource requests inside a company.

Metrics

Metrics are useful only when they help a team make a decision.

What Makes a Good Metric

OMTM: One Metric That Matters

OMTM is the one metric that best represents whether the current main risk is being reduced.

A good OMTM should answer three questions:

1. What is the current main risk?
2. Which metric best shows whether that risk is improving?
3. What action will the team take based on the result?

Common Metric Types

These types are useful as a checklist, not as the main framework.

Stages

The stage model answers two questions:

1. What is the main uncertainty of the current business?
2. How much evidence is enough to move to the next stage?

The standards below are directional. The actual threshold depends on business model, usage frequency, margin structure, acquisition cycle, and product maturity.

Empathy: Does a Real Problem Exist?

Step 1: Main Question

Whether the target user has a real, painful problem worth solving.

Step 2: Focus

Step 3: Possible OMTM

Valid interviews, reservation rate, or manual conversion rate. Choose one based on the riskiest assumption in the current iteration.

Step 4: Pass Logic

• Move forward when: the problem, target user, existing alternative, and willingness to act are clear.
• Risk of skipping: the team may build a solution for an imagined problem.

Example

Suppose the product is an AI code review SaaS. At this stage, the team should not start by measuring model accuracy alone. The first question is whether engineering teams already suffer from review delay, inconsistent review quality, or repeated manual checklist work. Strong evidence would include teams using custom scripts, written review rules, senior engineers spending repeated time on similar comments, or trial requests after seeing a manual demo.

Stickiness: Do Users Keep Using It?

Step 1: Main Question

Whether users keep using the product because it creates real value.

Step 2: Focus

Step 3: Possible OMTM

Activation rate, retention rate, or key action completion rate. Choose one based on whether the bottleneck is first value, repeat usage, or a specific retained-user behavior.

Step 4: Pass Logic

• Move forward when: retention is stable, core value is clear, and new users can repeatedly reach that value.
• Risk of skipping: scaling acquisition usually only exposes churn faster.

Example

For the AI code review SaaS, stickiness depends on whether teams repeatedly run reviews through the product after the first trial. A useful OMTM may be weekly active repositories with completed AI reviews, because it ties usage to the actual review workflow instead of counting logins or page views.

Virality: Do Users Bring New Users?

Step 1: Main Question

Whether user behavior can create new users without relying only on paid acquisition.

Step 2: Focus

Not every business must pass through the virality stage. Low-frequency, high-ticket, transaction-heavy businesses may move from stickiness directly to revenue validation.

Step 3: Possible OMTM

Share rate, invitation conversion rate, or viral coefficient. Choose one based on whether the current risk is motivation, conversion, loop efficiency, or referred-user quality.

Step 4: Pass Logic

• Move forward when: sharing has a real motivation, invited users activate and retain, and organic spread lowers acquisition cost without damaging quality.
• Risk of skipping: referral or sharing mechanisms may bring low-quality users without sustainable growth.

Example

For the AI code review SaaS, virality may come from collaboration rather than public sharing. If one engineer installs the tool and then invites teammates to comment, approve, or configure repository rules, workspace invite activation becomes more meaningful than generic share rate.

Revenue: Can It Make Money?

Step 1: Main Question

Whether product value can become repeatable revenue.

Step 2: Focus

Step 3: Possible OMTM

Paid conversion rate, LTV/CAC, or gross margin. Choose one based on whether the current risk is payment intent, acquisition efficiency, or delivery cost.

Step 4: Pass Logic

• Move forward when: revenue is repeatable, pricing logic is clear, and unit economics are acceptable.
• Risk of skipping: growth may amplify an unprofitable business model.

Example

For the AI code review SaaS, revenue validation begins when repeated review usage turns into paid team or company accounts. Trial-to-paid rate may be the first useful metric, but renewal rate, expansion seats, and LTV/CAC become more important once teams depend on the tool in their engineering workflow.

Scale: Can Growth Be Amplified Efficiently?

Step 1: Main Question

Whether growth can be amplified without losing efficiency, quality, or financial control.

Step 2: Focus

Step 3: Possible OMTM

Channel ROI, CAC payback period, or profit margin. Choose one based on whether the current risk is acquisition efficiency, cash recovery, or profitability.

Step 4: Pass Logic

• Keep scaling when: growth, quality, organization, and finance remain controlled.
• Risk of skipping: scale may amplify channel losses, quality failures, and organizational inefficiency.

Example

For the AI code review SaaS, scale should be judged after retention and revenue are working. At this stage, CAC payback, NRR, gross margin, and revenue per employee matter because growth may increase onboarding support, repository integration work, and inference cost.

Business Model Metric References

Stage-based metric references for common business models.

E-commerce / Transaction Platform

Core logic: traffic -> supply -> conversion -> repeat purchase -> profit.

SaaS / Subscription Business

Core logic: acquisition -> activation -> usage -> retention -> payment -> expansion.

UGC / Community

Core logic: users create content -> content is consumed -> interaction gives feedback -> creators keep contributing -> the community retains.