iterate-not-perfect

Source Metadata

Original cangjie-skill frontmatter from the distillation run:

id: f24
title: "迭代而非完美 — AI产品的渐进式改进"
book: "AI for Everyone"
author: "Andrew Ng（吴恩达）"
source: p20, p24
tags: [iteration, product-strategy, agile, continuous-improvement]
related_skills:
  - slug: ml-workflow, relation: depends-on
  - slug: statistical-acceptance, relation: composes-with
  - slug: start-small-find-partner, relation: composes-with

R — Reading (original quote)

"Don't try to make the AI system perfect before launching it... first release a 'good enough' version, then continuously iterate through user feedback" — p20

I — Interpretation (restate in your own words)

Pursuing "perfect AI" is one of the biggest traps in project management. Many teams spend too much time polishing models in the lab, trying to reach perfect metrics before launching—as a result, they miss the market window and also lose real user feedback.

Core idea: The improvement of AI products is acontinuous iterationprocess, not a one-time engineering effort.

1. Perfection is unattainable: As stated in statistical acceptance criteria, 100% accuracy is usually impossible to achieve.
2. Real feedback is most precious: Perfection in the lab is less valuable than real user feedback after launch.
3. Launch fast, iterate fast: First release an MVP version, and use real data to drive subsequent improvements.
4. The flywheel needs to start: The data flywheel can only start spinning after the product is launched.

The right approach: Define the "good enough" threshold, launch immediately once it is reached, establish a user feedback channel, and continuously iterate and improve.

A1 — Past Application (past application cases)

• Voice assistants: Early voice assistants (Siri, Alexa) were far less accurate than they are today, but they did not wait until "perfect" to launch. Through real usage data from hundreds of millions of users, these products continuously iterated, improving accuracy from about 70% initially to over 95% today. If they had pursued perfection before launching back then, they would not have today's market position.

A2 — Future Trigger (future trigger conditions)

Trigger scenarios：

• The team keeps polishing the model but delays launch
• The business side requires "complete functionality" before allowing release
• The team agonizes over a few percentage points of accuracy improvement and misses the release window

Language signals：

• "Not ready yet"
• "Let's optimize it a bit more"
• "Wait until the accuracy is a bit higher"
• "The features are not complete yet"
• "Let's test for a while longer"
• "Let's polish it a bit more"

Key distinction: When the team delays launch because ofpursuing perfection, use this framework to push for "launch first, then iterate."

E — Execution (execution steps)

1. Define MVP criteria: Negotiate with the team and business side to clarify the "minimum standard for launch" (such as core functionality being usable and accuracy reaching a baseline).
2. Set the release threshold: Quantify the MVP criteria into specific metrics, and release once they are met.
3. Establish a feedback channel: Design the user feedback collection mechanism before launch (error reports, satisfaction ratings, usage data).
4. Release the MVP: Don't wait for perfection; release once the threshold is met.
5. Iterate based on feedback: Collect user feedback and data, and formulate the next round of improvement plans.
6. Continuous iteration: Each iteration makes the product better, gradually approaching (but never reaching) perfection.

Completion criteria: The product is live and running, a user feedback channel has been established, and the next iteration plan has been formulated.

B — Boundary (usage boundaries)

Inapplicable scenarios：

• Safety-critical systems (medical, aviation — extremely high standards must be met before launch)
• First brand release (first impressions of a new product matter; an MVP may damage brand image)
• Legal compliance requirements (some features must be complete to operate legally)

Failure modes：

• Using "iteration" to cover laziness: not "release first, then iterate" but "ignore it after release"
• Ignoring user feedback: released but no feedback channel was established, so iteration becomes working in isolation
• Frequent major changes: every iteration is a major change, and users cannot adapt
• No iteration plan: released but no idea what to change next

Author blind spots：

• Andrew Ng did not discusshow to balance "fast launch" with "brand risk"— For well-known brands, a flawed AI product may cause lasting damage to the brand. It is recommended that well-known brands adopt a "soft launch" strategy (small-scale canary testing) to reduce risk.

Related skills

• ml-workflow — depends-on: Iterating rather than perfecting is a core concept of the deployment stage in the ML workflow, and it needs to be understood within the continuous delivery loop embedded in the overall workflow.
• statistical-acceptance — composes-with: Statistical acceptance criteria define the specific threshold for "good enough," and work together with the iteration philosophy — launch once the standard is met, then continue improving afterward.
• start-small-find-partner — composes-with: The strategy of starting with small partners and seeking success first is consistent with the iteration philosophy — rapidly iterating through small-scale validation to reduce the cost of trial and error.