Different progress answers different questions
A successful demonstration shows that a team achieved something under particular conditions. A customer returning to use the product provides different evidence. A payment provides another kind. University spinouts can lose this distinction when every development milestone becomes part of the same growth story.
Michael Seibel's YC teaching recognizes that some hard-tech MVPs require more substantial work. His PMF essay also cautions against treating funding or headcount as proof of demand. Jimhang's framework below applies these ideas; it is not a YC scoring system.
Source：Startup School Week 2 Recap: Michael Seibel, Adora Cheung, and Ilya Volodarsky · The Real Product Market Fit
Define the decision before building the test
Imagine an AI assistant that helps equipment technicians find repair information. Its first version could cover one machine type, one document collection and one category of question. Before testing, define an acceptable answer, the cases requiring an engineer and the decision the experiment will inform. A brief covering every industrial setting offers little interpretive discipline.
Hardware teams can narrow the task too. A hypothetical mowing robot could test one operation at an agreed controlled site. Reducing scope does not mean removing necessary safety provisions. The team and the responsible site operator should agree on the permitted conditions before deployment.
Keep four kinds of evidence distinct
Use this table to plan an experiment rather than to award a PMF badge. Projects may follow different sequences. Completing every row still does not establish that the business will work at every scale.
| Question | Observable evidence | What remains open |
|---|---|---|
| Does it work technically? | Conditions, test results and failures | Whether customers want to use it |
| Does it improve a task? | Task completion and repeated use | Whether procurement will approve it |
| Will someone pay? | Paid pilot and received payment | Whether delivery is economical |
| Can delivery repeat? | Support effort, failures and repeat orders | Whether it works at a larger scale |
Give every metric a denominator and a clock
Three remaining trial customers mean different things when the original group contained five or fifty. Record entry dates, opportunities to use the product and reasons for leaving. For an infrequent industrial workflow, behaviour per eligible task may be more informative than daily activity. Avoid importing a software metric without examining what customers actually do.
Record the human effort supporting the result. If a founder spends half a day preparing documents for every session, the delivery model still needs examination. Early manual support can be valuable, but the experiment log and cost assumptions should show it. An apparently automated interface should not obscure the actual work.
Tie the next investment to a decision
A weekly review can answer three questions: what evidence arrived, which assumption weakened and what should stop next week? Continuing, narrowing the setting, changing the approach and pausing are all legitimate outcomes. Additional features should not become the default response to uncertain demand.
When sharing an AI, robotics or university commercialization project with Jimhang Capital, bring the test boundaries, observation period and usage record. A project without revenue can still explain meaningful progress. The useful distinction is between what has been demonstrated and what the next product, staffing or funding decision must resolve.
Leave with a concrete work product
- Write down one decision the present version must inform.
- Separate technical, usage, purchasing and delivery evidence.
- Add denominators and observation windows to reported metrics.
- Define the conditions for continuing, changing or pausing.