When to open:When you need to build an MVP / validate critical assumptions / identify business milestones / want to use lean methods for low-cost validation. This wiki integrates perspectives from 3 schools.
Core in one sentence:Truman: "Without 'critical assumptions', Lean Startup can hardly be low-cost". Wang Huiwen (Tsinghua): "If your iteration cycle is shorter than others', you gain a huge competitive advantage". Three axes of critical assumptions: addition (list all) + subtraction (prioritize) + fast validation (low cost).
0. Core definitions
- Critical assumption = The specific, objective assumption behind business success or failure (replacing "I think")
- MVP = Minimum Viable Product
- Business milestone = The next critical assumption that most deserves to be validated
- Ω model = Propose assumption → Validate assumption → Iterate/eliminate
1. Cross-author consensus (4 points)
1.1 Critical assumptions are the soul of Lean Startup
"The Yitang five-step method without 'critical assumptions' is just an empty shell;Lean Startup without 'critical assumptions' can hardly be low-cost;New business discussions without 'critical assumptions' can hardly be scientific and efficient. "
"In the fields of business and management,true masters are all masters of critical assumptions. "
Communication replacement:
| ❌ Old | ✅ New |
|---|---|
| "I think..." | "My assumption is..." |
| "My view is..." | "I assume..." |
| Discussions about "what to do" | Discussions about "what to assume" |
1.2 Ω model (3 steps of critical assumption work)
提假设(Hypothesize)
↓
验证假设(Verify)
↓
迭代/淘汰(Iterate)
Key suggestions across 3 dimensions:
| Dimension | Focus |
|---|---|
| Mindset | Replace "subjective opinions" with "assumptions" / tag every assumption: holds / does not hold / pending validation |
| Communication | The team gets used to "My assumption is X / Validation method Y / Current status Z" |
| Tools | Critical assumption list + priority ranking + validation ROI |
1.3 Massive advantage of iteration cycles (Wang Huiwen classic)
Yitang / Complete 66-page notes on Wang Huiwen's Tsinghua product course 5 must-read books:
"*The Lean Startup*: Speed up validation and lower costs.If your iteration cycle is shorter than others', you gain a huge competitive advantage. "
1.4 Five soul-searching questions for assumptions
- Behind your "I think",what is the actual objective assumption??
- How do you plan to validate this assumption??
- If the assumption does not hold, what will happen to your business?
- How much cost is needed to validate this assumption??
- Are you 60% confident or 80% confident in this assumption?
2. Four major modules of yitang lean experimentation
Yitang / Complete intelligence research + lean experimentation system Part B:
2.1 The six "most" wastes
| Waste | Manifestation |
|---|---|
| 1. The busiest waste | The team works overtime every day but makes no core progress |
| 2. The most expensive waste | Investing heavily in things that have not been validated |
| 3. The fastest waste | Running fast but in the wrong direction |
| 4. The longest-lasting waste | Dragging a wrong project out for years |
| 5. The farthest-reaching waste | Wrong direction in the early stage leads to extremely high correction costs later |
| 6. The deepest waste | Getting used to replacing "results" with "being busy" |
2.2 Four principles of Lean Startup
- Build-Measure-Learn(Build-Measure-Learn) feedback loop
- Minimum viable product(MVP)
- Real, actionable goals(Validated Learning)
- Innovation accounting + pivot(Pivot)
2.3 Three axes of critical assumptions
| Axe | Action |
|---|---|
| Addition | List all assumptions (2/5/9 scoring method) + source from 7 channels |
| Subtraction | Rank (3 priorities: most fatal / most uncertain / lowest cost to validate) |
| Fast validation | 3 methods (user interviews / MVP / data testing) |
2.4 Four types of MVP
| MVP | Applicable scenario |
|---|---|
| Sketch / video MVP | Proof of concept (early Dropbox) |
| Facade MVP(Wizard of Oz) | Manually providing pseudo-automated services |
| Single-feature MVP | 1 core feature, cut all others |
| Key module MVP | Independent validation of a single module for complex products |
2.5 Systematic testing discipline
- Test only one variable at a time
- Define "success metrics" in advance
- Do not modify assumptions to match the data
- Eliminate failed assumptions in a timely manner
3. Business milestones (yitang exclusive)
Yitang / Complete five-step method system (critical assumptions + business milestones + five-step method 5 advancement stages + implementation) §II Business milestones (Truman's 7 versions of iteration / taken by 110,000 people):
3.1 Four core questions
| # | Question | Core answer |
|---|---|---|
| 1 | What exactly are you creating when starting a business? | Creating a commercial entity that sustainably creates value business entity |
| 2 | How to break down the logic behind a project? | Yitang five-step method |
| 3 | How to grasp the key to a business model? | Critical assumptions + unit model |
| 4 | How to validate a business at low cost? | Lean Startup + critical assumption ranking |
3.2 Business milestones ≠ time nodes
"Milestone" = the next critical assumption that most deserves to be validated, not time anchors like "launch product in June" "close Series A in August".
3.3 85% of business leaders have the wrong posture
Research findings(100 projects + 700+ cases + 110,000 students):
- Focus on resources and external opportunities
- but do not understand the underlying logic behind business success or failure
- There is a huge gap in depth between different CEOs looking at the same project
4. Yitang five-step method version 1-100 iteration (exclusive)
| Version | Theme | Focus |
|---|---|---|
| V1-V10 | Launch exploration | Bold assumptions + rapid research and validation |
| V10-V30 | Core refinement | Find the precise product core + establish a valid unit model |
| V30-V50 | Business model | Unit model baseline values + dynamic forecasting |
| V50-V100 | Growth + moat | Growth engine + long-term moat construction |
L1-L5 ranks:
- L1: Know the five-step method
- L2: Can use the five-step method to interpret others' projects
- L3: Can use the five-step method to break down own projects versions 1-3
- L4: Can use the five-step method to iterate 10-30 versions + drive with critical assumptions(passing line)
- L5: Can use the five-step method to iterate 50-100 versions + teach others
5. Wang Kai's pitfalls as corroboration (11 firsthand projects)
Wang Kai's AI-era entrepreneurship methodology and business judgment framework §12 + Collection of Wang Kai's product failure postmortems:
| Project | Key lesson |
|---|---|
| AI e-commerce guide site | Early token cost math didn't add up (not validated) |
| FastFacts | 300,000 ceiling for gold-bearing business + quantitative team was 5 seconds faster than us (no competitor analysis done) |
| AiPathly(AI job search) | Innovative product doing SEO was a mismatch (traffic assumption not validated) |
| Quanta Quest | Data access was blocked (infrastructure assumption not validated) |
| WhatsApp push bot | Overseas push was directly covered by IM (track assumption not validated) |
Common lessons:Math didn't add up (most cases) + died within 3 months after launch + ostrich mentality.
Wang Kai's 4 sayings:
- "Making a product is like making a chair: when there were no chairs in the world, don't worry about comfort when making the first one"
- "Big companies have 1 year of patience; independent development lives or dies in 3 months"
- "After validating that 'people want the chair', then add armrests"
- "Projects will most likely die, 90% don't make much money"
6. Candy: Duozhuayu launch + Chen Xianmin product selection (yitang exclusive)
6.1 Duozhuayu launch postmortem
- Second-hand book e-commerce
- Early assumptions: users are willing to buy/sell used books + reasonable prices + logistics works
- Validation method: started by manually taking orders from WeChat groups (Wizard of Oz MVP)
- Key turning point: launched the APP only after validation
6.2 Chen Xianmin Chinese-style burger product selection
- 50+ stores from 0 to 1
- Multiple rounds of assumption iteration: product / users / site selection / single-store model
- Used lean validation + systematic testing
7. How to choose — Lean Startup paths by identity
| Who you are | Primary method | Starting point |
|---|---|---|
| Business leader / entrepreneur | yitang lean 4 modules | Six most wastes + 4 principles + three axes + 4 types of MVP |
| Want to use critical assumption thinking | Truman Ω model | Propose → Validate → Iterate + 5 soul-searching questions |
| Want to find business milestones | yitang five-step method | Five-step method 5 cells + critical assumption ranking + currently most uncertain one |
| Want to avoid pitfalls | Wang Kai's 11 project lessons | Do the math before acting + live or die in 3 months + don't be an ostrich |
| Want to train rapid iteration | 1-100 version iteration path | V1-V10 launch / L4 passing line |
Universal discipline:
- Replace "I think" with "assumption"(Truman)
- Shorter iteration cycle than others = huge competitive advantage(Wang Huiwen)
- Do the math before acting(Wang Kai)
- Three axes of critical assumptions: addition + subtraction + fast validation
- Live or die in 3 months(independent development)
- Apply the 5 soul-searching questions to every assumption
8. Reference list
- Yitang / Complete intelligence research + lean experimentation system Part B —— Lean Startup 4 modules / six most wastes / 4 types of MVP / systematic testing discipline
- Yitang / Complete five-step method system (critical assumptions + business milestones + five-step method 5 advancement stages + implementation) —— Critical assumption Ω model / business milestones / 1-100 version iteration / Duozhuayu / Chen Xianmin
- Yitang / Complete 66-page notes on Wang Huiwen's Tsinghua product course —— *The Lean Startup* is one of the 5 must-read books / massive advantage of iteration cycles
- Wang Kai's AI-era entrepreneurship methodology and business judgment framework —— 11 firsthand projects / discipline for independent developers
- Collection of Wang Kai's product failure postmortems —— Detailed postmortems of WhatsApp / FastFacts / AiPathly
Related skills:
yitang-evaluate-business-milestone—— Business milestone judgmentyitang-extract-validation-assumption—— Extract and validate assumptionsyitang-master-key-hypothesis—— Critical assumption masteryitang-design-mvp—— MVP designyitang-systematic-validation-testing—— Systematic validation testingyitang-master-lean-validation—— Lean validation master
Sources and related materials
- Yitang / Complete intelligence research + lean experimentation system
- Yitang / Complete five-step method system (critical assumptions + business milestones + five-step method 5 advancement stages + implementation)
- Yitang / Complete 66-page notes on Wang Huiwen's Tsinghua product course
- Wang Kai's AI-era entrepreneurship methodology and business judgment framework
- Collection of Wang Kai's product failure postmortems
- Entrepreneurship Methodology (From 0 to 1) (Cross-Author Thematic Synthesis)
- Research Methodology / OSCAR / Research Hacker (Cross-Author Thematic Synthesis)
- Needs Analysis / JTBD / Product Core (Cross-Author Thematic Synthesis)
- In-Depth Postmortem / Failure Pitfall Case Library (Cross-Author Thematic Synthesis)
2026-10-18 Supplement: Layered validation of AI products from prototype, delivery to PMF
This section connects multiple 2023–2026 interviews from 42 Chapters with the critical assumption methods above. Revenue and retention figures in the programs are statements from the teams at the time and have not been independently audited; what is distilled below are verifiable questions and mechanisms, and you cannot declare your product has achieved PMF based on this. The main thread comes from Albert's PMF reflections, Hidecloud's product practice, Different evidence from three products, Answer.AI and Albert's creator community exploration two years later.
First break down the five assumptions, and select the one most likely to cause the business to fail
| Assumption | Required evidence | Things easily mistaken for evidence |
|---|---|---|
| Current technology can do it | Under real inputs, stably produce verifiable results, with known error boundaries | Curated demos, best single output, model leaderboards |
| Product can be delivered | Users can complete tasks on their own, bad outcomes are fixable and recoverable, wait times and costs are acceptable | Team runs it internally or engineers operate on users' behalf |
| Users truly need it | Target users use it proactively, come back when the need arises, and can clearly articulate alternatives | Founder likes it, industry friends say "it's cool" |
| Users are willing to pay | Actual payments, refunds, repeat purchases and renewals, with clear user segments and observation periods | Free retention, verbal expressions of willingness to pay, joining waitlists |
| The business is sustainable | Revenue from the corresponding cohort covers customer acquisition, inference, content, and service costs | Total revenue rising, short-term ad spend breaking even, expectation that model prices will drop |
These five items are not queued in the same order for all businesses. B2B companies with existing customers can test delivery and payment first; entirely new entertainment communities may start with supply and return visits; tools for defined tasks can charge earlier. The key is which question a single experiment answers; you cannot let one good-looking result substitute for the entire chain.
Gaotu case Further clarification: AI coverage rate, time saved, conversion rate, and per-lead output are distinct metrics. The official chapter states a "3–4x deal closure rate," yet the main text explicitly clarifies that the three-to-four-fold figure refers to per-lead efficiency, and acknowledges that only a small portion of traffic is accepted. Business reports should retain this discrepancy in measurement basis rather than selecting the largest number as the outcome.
Choose the starting point based on user expectations and current delivery capabilities
In 2024, Albert proposed two axes: whether users' delivery expectations are clear, and whether existing models can meet them. For resource-constrained teams, tasks with clear expectations that can be delivered with current capabilities make it easier to accumulate feedback; tasks involving open visions or dependent on future technologies require different levels of patience and resources. This framework helps decide on experiments, and does not imply that enterprise integration, security engineering, or frontier research are not worth pursuing.
Hidecloud's children's drawing case presents the other side: even when the technology is available, requiring children aged 5–10 to write prompts may not align with their usage abilities. Changes to input methods and response speed alter not only efficiency, but also whether interactions remain continuous. Product-model fit requires asking "how do target users express themselves, when do they see feedback, and how do they proceed after seeing it" before deciding on the model, interface, and engineering; it is not a matter of first picking the most powerful model and then figuring out where to place the buttons.
When turning this into an executable experiment, first define one specific user, one real scenario, and one acceptable deliverable, then record inputs that can lead to failure. Let users use it themselves, and observe where failures occur: inability to input, incorrect results, inability to revise, lack of a next step, or simply no demand at all. Different failures require fixes at different layers, and cannot all be attributed to "the model not being strong enough."
Controllability of the final step is often more important than a stunning first impression
ACE Studio, among the three PMF interview subjects, noted that one-click music generation may produce 85% satisfaction, yet the final short segment can render the entire track unusable; regenerating would in turn ruin the previously good parts. Its product choice was to allow note-by-note, lyric, and vocal style modifications rather than unlimited full-track generation. The 85% figure is an illustrative example and should not be treated as a precise measurement. The transferable question is: can users retain the parts they are satisfied with, modify only the unsatisfactory parts, and integrate the result into their existing workflow?
Early Dify placed prompt, knowledge material, model, and tool debugging into ongoing operations, helping people with business expertise participate in iteration. The common ground between the two is that delivery includes modifiability and maintainability; the difference is that local control over musical works and enterprise application operations do not share the same interface, so one cannot be mechanically copied from the other.
Wanaka also provides a counterexample: for the positioning and placement of 3D objects, direct manual manipulation may be easier than natural language description. Letting AI handle logic while humans directly adjust spatial layout and details can be more appropriate than "routing all tasks through a chat box." How much of the workload AI takes on is a design choice; acceptance still hinges on whether users can complete the work they want.
For retention, ask "who comes back for what reason," rather than relying solely on an industry threshold
FlowGPT distinguishes between single-app retention, content category retention, and platform retention: users may switch entertainment Bots yet still return weekly for similar content, while relational companionship may depend on the same character. The three layers should be measured separately; one cannot conclude the platform is failing simply because users switch characters, nor treat platform return visits as proof that a stable relationship has formed.FlowGPT close reading does not provide full denominators or time periods, so its observations are retained here rather than treated as universal benchmarks.
The three PMF interviews also cannot be lumped together: AiPPT focuses on actual payment and customer acquisition cost for low-frequency tasks; ACE Studio looks at professional user workflows and payment; NieTa first checks whether character creation with leads improves return visits, consumption, and sharing, then confirms commercial willingness through ads, microtransactions, and repeat purchases. The cited "421" retention experience line from the program lacks a unified cohort definition and cannot be directly used as a passing threshold for other products.
For subscription products, new customer and renewal cohorts should be examined separately. Albert noted that accumulated renewals may improve subsequent gross margins, but renewal rates, service costs, refunds, and customer acquisition prices all change; "the third year will definitely be more profitable" is not a necessary conclusion of this logic. Budget expansion should be proven by one's own real cohort data.
Creators, consumers, and relationship networks need to be validated separately
NieTa originally extrapolated from "users are willing to generate character wallpapers" to "users are willing to create comics," but later found a missing layer of people willing to construct stories. It shifted to having professional creators provide plot leads, while ordinary users bring in their personal characters, generate segments, and accumulate memories. What needs to be tested is whether the leads are simultaneously easy enough to apply while preserving personal expression, rather than simply providing more free input boxes.
Wanaka's observation on acquaintance distribution complements this: classmates, school maps, and friend avatars may not look appealing to the whole internet, but hold value for specific relationships. The mutual success of the FlowGPT platform and its creators depends on production, exposure, consumption, and re-creation. One cannot directly deduce from "generation capabilities are cheap" that recommendation feeds, acquaintance social networking, or creator communities will necessarily take off.
AI music interview further reminds: being able to generate does not equal willingness to create; users still need inspiration and curated supply, and works with better aesthetics may outperform content that is "completely mine." Evaluation should adopt ordinary consumer standards, avoiding lowered requirements simply because a work is made by AI.
Retain disagreements and temporal changes, and choose success criteria suited to your own stage
In 2024, Albert emphasized cash flow, ongoing need, and verifiable delivery; when exploring merging.live in 2026, he placed greater emphasis on three layers: response, resonance, and return. The two cannot be seamlessly synthesized into "always prioritize profit first" or "only influence matters"; personal creators, funded companies, and different stages have different goals and cost responsibilities. His team built dozens of tools in two months with zero revenue at the time, indicating that creation speed and commercial outcomes should also be recorded separately.
The operational choice presented in this section is: first clarify whether the current task is validating usability, user value, relationships/supply, payment, or unit economics, then find one piece of evidence sufficient to overturn your own judgment. Assumptions without sufficient evidence remain to be verified; data that contradicts expectations is used to correct attribution, rather than rewritten into a success story.
Check Product-Market Fit and Product-Model Fit side by side
Zhang Hailong's 2024 Coding interview separated Product Market Fit (whether interactions, scenarios, and pricing are accepted by the market) from Product Model Fit (whether the current model can support the experience). Cursor's cross-position editing example illustrates that a desired interaction can be defined first, but must wait until capability, latency, and context engineering simultaneously reach usability; conversely, the ability to generate code does not prove that people want to use the software. Checking new features against these two records helps avoid misattributing demand problems to technology, or mistaking demo hype for market validation. The judgment at the time that Agents lacked clear PMF is retained within its 2024 context and should not be used to override subsequent product developments.
English version
October 18, 2026 addition: Validate AI products in layers, from prototype and delivery to product-market fit
This section connects several 2023–2026 interviews from the 42 Zhangjing podcast with the critical-assumption method above. Revenue and retention figures are statements made by the teams at the time, without independent audit. The aim is to extract questions and mechanisms that can be checked, rather than declare that your own product already has product-market fit (PMF). The main sources are Albert's reflections on PMF, Hidecloud's product work, the different evidence used by three products, Answer.AI, and Albert's exploration of a creator community two years later.
Separate five assumptions, then choose the one most likely to break the business
| Assumption | Evidence needed | What can be mistaken for evidence |
|---|---|---|
| The technology can do it today | Real inputs consistently produce inspectable results, with known failure boundaries | A curated demonstration, a single best-case output, or a model leaderboard |
| The product can deliver | Users can complete the task themselves, correct and recover from poor results, and accept the wait and cost | An internal success or an engineer operating it for the user |
| Users actually need it | Target users choose to use it, return when the need arises, and can identify their alternatives | The founder likes it, or industry friends call it “cool” |
| Users will pay | Actual payments, refunds, repeat purchases, and renewals, with a defined audience and observation period | Retention among free users, stated willingness to pay, or joining a waiting list |
| The business is sustainable | Revenue from the relevant cohort covers acquisition, inference, content, and service costs | Rising total revenue, a short period of acquisition breaking even, or an expected fall in model prices |
These assumptions do not have to be tested in the same order for every business. An enterprise with existing customers may start with delivery and payment. A new entertainment community may first need content supply and returning users. A tool for a well-defined task may charge earlier. The key is to state which assumption an experiment answers, rather than let one attractive result stand in for the entire chain.
The Gaotu case makes the distinction more concrete: AI coverage, time saved, conversion rate, and output per lead are different metrics. The official chapter title says “3–4 times the closing rate,” but the discussion identifies the three- to fourfold figure as output per lead and acknowledges that the experiment handled only a small portion of traffic. A business report should preserve that difference in definitions instead of choosing the largest number as its headline result.
Start with user expectations and what can actually be delivered today
In 2024, Albert proposed two axes: whether users have clear expectations for the deliverable, and whether existing models can meet them. For a team with limited resources, a clearly expected result that can already be delivered makes feedback easier to accumulate. An open-ended vision or a task that depends on future technology requires different resources and patience. This framework helps select experiments; it does not imply that enterprise integration, security engineering, or frontier research is unworthy of investment.
Hidecloud's example of a drawing product for children shows another constraint. Even when the technology works, asking children aged five to ten to write prompts may exceed their ability to use the product. Input methods and response speed affect more than efficiency: they can determine whether an interaction remains continuous. Product-model fit requires asking how target users express themselves, when they see feedback, and what they can do next, before selecting the model, interface, and engineering approach. It is not a matter of choosing the strongest model first and then deciding where to put the buttons.
For a concrete experiment, specify one user, one real situation, and one acceptable deliverable, then record inputs that could cause failure. Let users operate the product themselves and observe where it breaks: they cannot enter their intent, the result is wrong, they cannot edit it, there is no useful next step, or they never needed it in the first place. Different failures require changes at different layers. They cannot all be explained away as “the model is not strong enough.”
Control over the final step often matters more than the initial surprise
In the interview about three products and PMF, ACE Studio explains that a one-click music generation result might be 85% satisfactory, yet one small remaining section can make the whole song unusable. Generating the song again may ruin the parts that were already good. Its product response is to let users edit individual notes, lyrics, and singing techniques, rather than repeatedly regenerate entire songs. The 85% figure illustrates the problem; it is not a measured accuracy score. The transferable question is whether users can preserve the parts they like, change only what they dislike, and use the result in their existing workflow.
Early Dify places prompts, knowledge materials, models, and tool debugging within ongoing operations so that people who understand the business can participate in iteration. Both approaches treat editing and maintenance as part of delivery. Their differences matter too: local control over a music work and enterprise application operations do not call for the same interface, so one cannot simply copy the other.
Wanaka provides a counterexample to making natural language the universal interface. Directly moving and placing a 3D object may be easier than describing its location in words. Letting AI handle logic while people adjust space and details can work better than putting every task into a chat box. How much of the work AI performs is a design choice; acceptance still depends on whether users can make the work they intended.
Retention asks who returns and why, rather than whether a product clears one industry threshold
FlowGPT distinguishes retention for an individual application, a content category, and the platform. A user may change entertainment bots while continuing to return each week for that kind of content. Relationship-based companionship, by contrast, may depend on returning to the same character. These three levels should be measured separately. Switching characters does not by itself establish platform failure, and returning to the platform does not establish a stable relationship. The FlowGPT interview does not provide all denominators and observation periods, so its observations are retained here without being turned into universal benchmarks.
The three PMF cases also use different evidence. AiPPT focuses on actual payment and acquisition costs for a low-frequency task. ACE Studio examines professional workflows and payment. NieTa first checks whether guided character creation increases returns, usage, and sharing, then uses advertising, small payments, and repeat purchases to test commercial willingness. The interview's “421” retention rule of thumb does not specify a consistent cohort definition—a group of users who enter during the same period—and should not be adopted directly as a pass mark for another product.
Subscription products should also distinguish new-customer and renewal cohorts. Albert suggests that accumulated renewals may improve later margins, but renewal rates, service costs, refunds, and acquisition prices all change. The logic does not guarantee that “the third year will be more profitable.” A team's own observed cohorts must justify expanding its budget.
Validate creators, consumers, and relationship networks separately
NieTa initially moved from “users want to generate character wallpapers” to “users want to create comics,” then discovered a missing layer: people willing to invent stories. It shifted toward professional creators supplying plot prompts, while ordinary users bring their own characters into those situations, generate scenes, and accumulate memories. The question is whether those prompts are easy enough to use while retaining room for personal expression, rather than whether users have been given more blank input boxes.
Wanaka's observations about distribution among friends complement this finding. Classmates, school maps, and representations of friends may not interest the whole internet, but can have value within a particular relationship. FlowGPT's platform and creators depend on a cycle of production, exposure, consumption, and further creation. Cheap generation does not by itself establish that a recommendation feed, a friends-based social product, or a creator community will necessarily work.
The AI music interview adds another warning: being able to generate content does not mean people want to create it. Users still need inspiration and curated supply. A work with stronger aesthetic quality may also beat one that feels “entirely mine.” Evaluation should use ordinary consumption standards, rather than lower expectations because the work was made with AI.
Preserve disagreement and changes over time, and choose success criteria that fit the current stage
In 2024, Albert emphasized cash flow, enduring need, and verifiable delivery. In his 2026 exploration of merging.live, he placed more weight on response, resonance, and return as three distinct levels. These views cannot be seamlessly reduced to either “always earn money first” or “influence is all that matters.” Individual creation, venture-funded companies, and different business stages have different objectives and cost responsibilities. His team built dozens of tools in two months while reporting zero revenue at the time, illustrating why creation speed and commercial results should be recorded separately.
The operating choice proposed here is to identify what the current task is testing: usability, user value, relationships and supply, payment, or unit economics. Then find evidence capable of disproving the team's judgment. Ideas without enough evidence remain hypotheses. Unexpected data should correct the explanation, rather than be rewritten into a success story.
Check product-market fit and product-model fit side by side
Zhang Hailong's 2024 coding interview separates Product Market Fit—whether the market accepts the interaction, scenario, and pricing—from Product Model Fit—whether the current model can support the experience. Cursor's example of editing across multiple code locations shows that a desired interaction can be defined before model capability, latency, and context engineering jointly make it practical. Conversely, generating code does not prove that anyone wants the resulting software. Keeping these two records for each new feature helps prevent demand problems from being mislabeled as technical failures, or demonstration excitement from being mistaken for market validation. The interview's judgment that agents had not yet found clear PMF remains a 2024 observation; it does not override subsequent product developments.