Chapter 30 · How a Crypto Startup Finds PMF
When is a token unnecessary?
- Capabilities practiced
- ResearchSystem ThinkingBuilder
- Hands on
- For one of your ideas, explain who pays, why it must be on-chain, and whether it works without a token.
- AI Lab
- Have AI play three roles—user, investor, regulator—and raise three objections from each. Answer them one by one.
A Real-World Problem
In one week, three founders ask the same question: “When should we launch a token?”
The first has only a document and three prototypes. They believe a token is needed to attract early users and funding.
The second has operated for seven months, with 200 weekly returning users and no incentives. Users pay fees and voluntarily help newcomers. The reason: competitors launched tokens, so waiting means falling behind.
The third launched four months ago. Many addresses registered, but almost nobody returned. They want a token to attract people, expecting retention to follow.
The same question means three different things.
For the first, it concerns funding and bootstrapping. For the second, ownership distribution and long-term structure—with a real asset to distribute.
For the third, it is not actually a token question. The question is why nobody returns. A token postpones that answer for at least a year, using incentives to create addresses resembling users and temporarily improve the curve until rewards end.
This chapter separates these situations, with one central question: when is a token unnecessary?
It is Part A's final builder-perspective question and leads directly to the capstone.
Thought Experiment
Two teams start the same idea in the same month.
Team A launches a token in month one, using it for incentives, fundraising, and airdrop expectations.
Team B launches no token, focusing on product, users, and fees.
Observe eighteen months.
Month 1 A: 50,000 addresses, a steep curve, 20,000 community members, and media coverage. B: eleven users, four of them friends.
Month 3 A: 30,000 daily active addresses, substantial TVL, successful fundraising. B: sixty users, twenty returning weekly. The team has changed direction three times.
Month 6 A: 25,000 daily active addresses. Incentives decline as planned; the community asks why rewards are shrinking. B: 300 users, 120 returning weekly, and users bringing friends. For the first time, someone says closing the product would cause real trouble.
Month 12 A: incentive budget nearly exhausted, daily activity at 2,000. The team debates another round; community discussion shifts from product to price. B: 900 users, 400 returning weekly. Fees cover servers and two salaries. The team knows who these 400 people are, which feature they use, and why they depend on it.
Month 18 A: 1,800 daily active addresses, mostly waiting for incentives. How many of the original 50,000 genuinely needed the product? Nobody knows; it was never measured. B: 2,000 users, 1,100 returning weekly. A token launched now can have an explicitly defined purpose, with 1,100 users as a distribution basis.
This does not prove B is always better. A's route can be right under conditions discussed below.
The specific lesson is that a token postpones the answer to genuine demand by twelve to eighteen months.
Those months were meant to answer it. For a team without proven demand, token-bought time is borrowed from validation, not added to it.
Your Decision
You have an idea and twelve months of startup funding. What comes first?
What Happens
The options lead to one principle:
Prove people use it without a token before deciding whether to issue one.
“Prove” means an executable test, not an attitude.
Classify projects by token necessity. This is the table to take away:
| Category | Token role | Recognition | Correct order |
|---|---|---|---|
| Necessity | Mechanism cannot operate without it | Identify the exact step that breaks when removed | Early issuance can work, with an explicit mechanism role |
| Accelerator | Faster with it, functional without it | Product still works, but grows slowly | Validate demand before accelerating |
| Disguise | Replaces demand that does not exist | No reason for the project without the token | Do not issue; solve demand first |
The first category is smaller than commonly assumed, mainly covering two structures.
Economic incentives maintain a decentralized network's security or supply. Strangers supplying compute, storage, or bandwidth need payment independent of any one company—a genuine mechanism role.
Ownership itself is part of the product. Tokens carry governance and income rights distributed to users.
The third category is what this chapter helps you avoid. Test it by removing the token from the description. If only an unwanted product with an elaborate economic model remains, the token temporarily conceals that lack of demand.
Build a Model
Four Token-Necessity Questions
Ask in order, stopping when the earlier answer is missing:
- Does it work without a token?
- Who changes behavior because of it?
- What replaces it for twelve months?
- What remains after a 90% price fall?
| Question | Required answer | Inadequate answer |
|---|---|---|
| 1. Does it work without a token? | Exact broken step and why alternatives fail | No token means no incentives—a tautology |
| 2. Who changes behavior because of it? | Specific people and behavior the product genuinely needs | More community participation—not a behavior |
| 3. What replaces it for twelve months? | A concrete bootstrapping plan | A small beta—postponement rather than a plan |
| 4. What remains after a 90% fall? | Remaining product, users, and revenue | Our value is not price—then identify it |
Question two exposes problems most readily, requiring you to ask whether the behavior is genuinely needed.
Many incentives buy only the reward-qualifying action, with no product value. Threshold design in Chapter 28 addresses this. Without knowing the needed behavior, no team can design effective thresholds.
Why Crypto PMF Is Hard to Measure
Web2 has established signals: flattening retention, organic growth, paid conversion, and users distressed by a product's disappearance.
Subsidies can imitate all these signals in crypto.
| Web2 PMF signal | Crypto contamination |
|---|---|
| User growth | Incentives can multiply it fortyfold |
| Flat retention | Continued incentives keep the curve flat |
| Organic growth | Friend referrals may mean bringing friends to collect rewards |
| Paid conversion | Fees paid may be below incentives received |
| Retained capital | Funds may follow yield rather than the product |
Remove subsidies before judging crypto PMF. Measure four signals afterward:
| Signal | Definition | Measurement |
|---|---|---|
| Self-funded retention | Returns during a fully unincentivized window | 30/60/90 days after incentives end |
| Willingness to pay | Real costs for an unincentivized action | Interactions excluding incentive-related calls |
| Organic origin | New users not originating from reward pages | Call sources and first-interaction entry points |
| Retention depth | Funds left overnight or for weeks | Distribution of capital holding durations |
The fourth is underrated and hardest to fake. Leaving funds in your contract for a week expresses more trust and dependence than clicking once.
The strongest off-chain signal is real distress when you plan to remove a feature. Subsidies cannot buy dependence.
Bootstrapping Without Tokens
Question three needs a concrete answer. Four repeatedly tested routes:
| Route | Method | Suitable products |
|---|---|---|
| Supply the first side yourself | Team provides supply until demand develops | Two-sided markets with manageable supply |
| Serve an existing struggling group | Help a small group using poor alternatives | Tools and infrastructure |
| Be a component, not an entry point | Integrate into existing distribution, as in Chapter 29 | Protocol and interface products |
| Use cash incentives instead of tokens | Honest, bounded subsidies without fixed long-term structure | Stages needing subsidies before token issuance |
Subsidies do not necessarily mean tokens. Equivalent cash incentives can work similarly, with immediate visible costs, treasury-bounded spending, and no locked-in structure.
Unwillingness to spend equivalent cash suggests uncertainty about how real the token expenditure is. Every team considering issuance should ask this.
Real and Rented Network Effects
Claimed network effects are common in pitch decks. Crypto has three sources of very different durability:
| Source | Mechanism | Durability | Test |
|---|---|---|---|
| Liquidity | Depth → experience → users → depth | Moderate: real, but movable by subsidies | Depth after subsidies stop |
| Integration | More integrations → harder replacement → more integrations | Strongest: replacement requires others to change code | Calling external contracts and share of calls |
| Assets and standards | Widely accepted receipts → further acceptance | Strongest, hardest to establish | Third parties using receipts as collateral or a unit of account |
Liquidity effects are most frequently claimed and easiest to dislodge. In Chapter 26, capital leaves when incentives stop. A deeper-paying competitor can take a depth-only moat in weeks.
Integration effects are strongest because replacement imposes genuine engineering costs, another reason Chapter 29 places them first.
Decision Sequence
Compress the chapter into four steps:
- Find real paying users
- Make them return without incentives
- Show scaling improves usefulness
- Then decide whether to issue a token
Scaling improves usefulness tests whether network effects are needed. If growing from 100 to 10,000 users does not improve value per user, it is a tool rather than a network—and tools usually do not need tokens.
What It Is Called
A product matches a group's real needs, demonstrated through sustained, voluntary, costly use.
Retest every qualifier in crypto: sustained without incentives, voluntary excluding reward seekers, and costly excluding rewards greater than spending.
Always remove subsidies first and inspect what remains. Otherwise PMF discussions describe reward attractiveness.
Whether users return after first use.
Chapter 28 supplied measurement. Here the definition is stricter: return rates of unincentivized paying addresses in a completely reward-free window.
The number is often painfully small but honest. A team that does not know it cannot judge its situation.
More users make the product more useful to each user.
Crypto sources are liquidity, integration, and assets/standards, increasing in durability. Liquidity is most commonly claimed and easiest to dislodge.
Test simply: does per-user value rise from 100 to 10,000 users? If not, it is a tool. Tools can be good businesses, but usually need neither tokens nor network-based valuation.
Starting a market that requires both sides to be present.
This is the strongest irreplaceable use of incentives and the reason early tokens may be right. Test whether the subsidized side begins earning independently as support declines.
Design the decline from day one and track unsubsidized income as a share of total income. Rising means the market takes over; flat means subsidies replace demand itself.
What remains after removing the token.
Three answers classify projects: an inoperable mechanism, necessity; a slower but valid product, accelerator; nothing, disguise.
Remove every token reference from your project description and read what remains. If you cannot explain why it should exist, token design is not the problem.
This is question three of the analysis toolbox's twelve questions and this chapter's subject.
Hands-on
This is Part A's hardest lab because outside materials cannot answer for you. Earlier labs studied others; this tests yourself.
Without an idea, use something you recently thought someone should build, or your current project.
First: who pays? Identify a specific person.
Do not write users. Describe who they are, their current solution, its costs, and monthly money or time lost.
Person: Job / role / scale
Current solution: Specific tool or workflow
Current cost: Money, time, risk, with an approximate scale
Willingness to pay: A number, even estimated
How I know: Guess? Asked? How many people?The last line is the core. If it is a guess, stop and ask five people before continuing.
Second: why must it be on-chain?
Run a replacement experiment: which step breaks if a regular database replaces the chain?
Replacing the chain breaks:
□ Independently provable asset ownership → Chain necessary
□ Trustless settlement between strangers → Chain necessary
□ Rules protected from unilateral change → Chain necessary
□ Records verifiable by anyone → Chain necessary
□ Nothing → Chain unnecessary; not necessarily badNothing breaks is not a failed lab. Valuable products often need no chain. But this changes everything afterward: an unnecessary chain almost certainly means an unnecessary token.
Third: does it work without a token? Remove tokens and reread.
Write a 300-word description without token, airdrop, incentive, or governance.
Read it and answer:
- Does the project still have a reason to exist?
- Would the person from step one pay for it?
- If so, what problem does the token solve?
Question three is your token-necessity argument. If unavailable, the normal answer is no token needed yet.
Answer each of the four necessity questions in a paragraph.
1. Which exact step breaks without a token, and why do alternatives fail?
2. Who changes behavior because of it? Do I genuinely need that behavior?
3. What replaces it for twelve months? A concrete plan, not a small beta.
4. What remains after a 90% price fall? Product, users, and revenue, quantified.Question three should use self-supplied first-side liquidity, an existing struggling group, integration into distribution, or cash incentives.
Talk to five real people. Do not skip this.
They must match step one's group and cannot be friends or colleagues. Ask only three questions without pitching:
1. How do you handle this now? Describe the actual workflow.
2. Which step is most troublesome? Let them answer without offered choices.
3. Have you paid to solve it? How much? This matters most.Do not start pitching after the first two questions. Polite positive feedback destroys the conversation's information value.
Revise step one's table afterward. Five different answers about the hardest step mean five individuals, not one coherent group.
Write a minimal eight-week demand-validation plan.
Claim to test: A falsifiable sentence
Method: What to do and who uses what
Success criterion: A number measurable within eight weeks
Failure criterion: The result that disproves the assumption
Does this need a token?The failure criterion is hardest and most valuable. Without it, every result can be described as promising.
You have a paying person, a chain-necessity judgment, a token-free description, four answers, five conversation records, and an eight-week plan.
Together, these form the complete “is this worth building?” section of the capstone. Apply them to others' projects and you may understand their situation better than most investors.
AI Lab
Use AI as a mirror rather than a content producer.
The perspectives have distinct concerns: users ask usefulness, investors ask viability, and regulators ask boundaries. Founders usually prepare only one category.
Complete the previous lab first, so there is something concrete to challenge.
Here is my project:
<Paste the 300-word description without token vocabulary>
<Paste the four token-necessity answers>
Take three fictional perspectives, with three challenges each:
One: target user.
Someone using an existing solution, concerned with convenience, cost, and reliability.
Ask about usage, not token prices.
Two: investor.
Someone familiar with similar projects. Include:
Why a token is needed, whether users remain after subsidies, and who pays.
Three: regulatory perspective.
An observer concerned with consumer protection and fund safety.
Target specific product steps, not generic compliance worries.
Make every challenge specific to my project.
After each, state what an inability to answer implies.
Finally, identify the perspective I am least likely to answer well, and why.
All perspectives are fictional analytical devices. Do not imitate real people or
institutions, or claim to represent their positions.Answer all nine challenges. Use only two sentence forms:
“We have verified ___, supported by ___.”
“We have not verified ___; we plan to use ___ before ___.”No third form, such as “we will solve this.” It provides no information and is easiest to write.
Count answers using the first form. The ratio measures current validation.
Four common model errors, ordered by danger:
- Users ask price questions. Listing questions mimic community chatter instead of real needs. Rewrite the prompt.
- Generic regulatory concerns. Regulatory uncertainty applies everywhere. Require specific custody, withdrawal, and responsibility questions.
- Converging viewpoints. Three similar sets mean perspective switching failed.
- Overly gentle challenges. Add an assumption that the reviewer tends to reject the project and must explain why.
The final section is the exercise's focus. Its answer may be wrong, but the question forces your own reflection, often revealing what you have been avoiding.
Verify these points yourself after using AI
- Are user challenges about experience or token price? The latter is not a user perspective
- Does the investor ask why a token is needed and what happens after subsidies?
- Do regulatory challenges target concrete product steps rather than generic compliance concerns?
- Do the perspectives repeat questions? Repetition means the viewpoint did not change
- How many challenges were new to you? None suggests the prompt was not sharp enough
- How many answers say we will solve it rather than we have verified it?
- Most importantly, which challenge can you not answer? Record it as a real risk
- Does it imitate a real institution or person? Treat that material as fictional
Real-World Case
Some projects follow a consistent route: build needed developer services, fund them with subscriptions, usage charges, or investment, operate for years, accumulate dependent integrators, then consider a token.
At issuance, they can explain its responsibility: paying network resource costs, distributing node income, or distributing ownership to existing users.
This is accelerator becoming necessity: after proven demand, tokens solve a specific mechanism issue rather than manufacture demand.
It is slow and can look behind during hot markets. But on launch day, the team knows its users.
Another consistent curve peaks in attention and price near launch, declines afterward, and never sees product usage catch up.
Reviews blame markets or insufficient marketing. This framework identifies an earlier issue: the project never asked whether people would use it without a token.
Issuance turns an unvalidated hypothesis into a priced asset. Attention then shifts from usefulness to preventing price declines, requiring different, often conflicting actions.
Chapter 25's warning returns: more detail in Token than Product is a strong signal.
Early tokens are not always wrong. Demand must already be understood, or issuance buys a harder-to-reverse position rather than time.
A team uses points for guidance without fixing token structure, while observing real behavior.
Execution produces two different outcomes.
Good execution treats points as an observation tool, measuring what participants do outside points: unincentivized features and overnight funds. After twelve months, core users are known and shape token design.
Poor execution treats points as a token presale. Metrics remain contaminated, redemption pressure grows, and users remain unverified. Accrued liabilities make exit harder than before.
The difference is preserving an unincentivized observation area. Always leave some features without rewards; their data is your only clean sample.
Strangers supplying compute, storage, bandwidth, or validation need continuing payment independent of a single company; otherwise that company's closure halts the network.
Tokens are the payment layer and security budget, not marketing. Removing them yields a clear answer: the supply side disappears within days.
Test what goes wrong if one company pays suppliers in cash. Merely higher cost means accelerator. Losing censorship resistance and continuity, the very reasons users choose it, means necessity.
This filters out most projects claiming necessity.
Change One Variable
This is the real risk of the no-token route, nearly inevitable in liquidity-dependent sectors.
Ask whether departing supply followed subsidies or was never truly yours. Yield-driven suppliers also leave competitors when support stops. If your product was worse, subsidies accelerated an existing outcome.
Prioritize protecting demand, since supply follows it; deepening integration, the durable connection from Chapter 29; and temporary cash counter-subsidies if needed, honest and bounded without fixed token structure.
Avoid rushing issuance to retaliate, making your most irreversible decision when least in control.
This real pressure is often described as an industry rule.
Turn it into a discussable schedule: the necessity argument, verifiable issuance conditions such as unsubsidized retention, and interim certainty for investors.
A token commitment in funding terms can move issuance from completed demand validation to investors' expected date. Misalignment will drive later product choices.
The condition can be reasonable for necessity-category projects, which should have a token plan already. Disagreement concerns accelerators and disguises.
This is one customer, not PMF. The product may silently become tailored solely to that company.
It remains a useful starting point. Find second and third unrelated sources immediately to test generality.
Ask whether the pain is industry-wide or specific to their workflow, how reusable customization is, and revenue remaining if the company disappears tomorrow.
Zero remaining revenue means an outsourcing project rather than a product. Both can be good businesses but require different decisions; outsourcing almost certainly needs no token.
It is a tool rather than a network. This is a valuable diagnosis, not bad news.
You do not need token-subsidized network bootstrapping. Growth can be linear, without chasing exponential curves that encourage useless work. Charge fees rather than relying on tokens.
Teams sometimes misrepresent this because networks attract investment more easily. They then pursue scale subsidies, user counts, and tokenomics—unhelpful or harmful to a tool.
The appropriate route is Chapter 26's statement: improve take rate, retention, and renewals until line five is positive. Unexciting, but independent of sentiment.
Takeaway Questions
The hardest version asks which problem your own project solves.
Add whether you guessed or asked five real people. The lab's fifth step forbids pitching after the first two questions to avoid polite feedback.
Three answers classify projects: necessity, accelerator, disguise.
Remove tokens from the description and reread. No remaining reason to exist means token design cannot solve the problem.
Question four asks what remains after a 90% token fall.
Separate product from speculation. Remaining product, users, and revenue are the business foundation. An indescribable foundation means speculation currently dominates.
A research tool becomes a building standard: answer before issuance.
Use unsubsidized retention, willingness to pay, organic origin, and retention depth. A token temporarily conceals poor signals without changing them, usually for twelve to eighteen months.
Chapter Check
Remove tokens from the description and inspect what remains.
- An inoperable mechanism means necessity. Identify the broken step and lack of alternatives, typically independent payment to unfamiliar suppliers.
- A slower valid product means accelerator. Validate demand first.
- Nothing means disguise. Solve demand, not token design.
Test necessity by asking about cash payments from one company. Higher costs imply accelerator; lost censorship resistance and continuity central to demand imply necessity.
This filters most self-described necessity projects.
Campaigns multiply users, ongoing rewards flatten retention, referrals recruit reward seekers, and fees paid may be below rewards earned.
First remove subsidies, then inspect:
- Self-funded retention in fully unincentivized windows.
- Willingness to pay excluding incentive-related calls.
- Organic origin outside campaign pages.
- Retention depth with funds remaining overnight or for weeks.
The fourth is hardest to fake. Also inspect genuine distress over removing a feature. Subsidies cannot buy dependence.
Four routes fit different products:
- Supply the first side yourself until demand develops, when the team can bear supply costs.
- Serve an existing struggling group, suitable for tools and infrastructure.
- Be a component in existing distribution, suitable for protocols and interfaces.
- Use cash incentives, honest and bounded without locked long-term structure.
Subsidies need not mean tokens. Unwillingness to spend equivalent cash suggests uncertainty about the expenditure's reality.
Three possible sources differ greatly:
- Liquidity improves depth and experience. Most commonly claimed, easiest to dislodge through higher subsidies. Inspect depth after support stops.
- Integration raises replacement costs. Strongest, because others must change code. Count external callers and their call share.
- Assets and standards gain broad acceptance. Strong but hard to build. Count third-party collateral or accounting uses.
Ask whether per-user value increases from 100 to 10,000 users. If not, it is a tool—usually without need for tokens or network-style decisions.
Real paying users → returns without incentives → scaling improves usefulness → token decision.
There is no standard answer. Check:
- Were payers discovered through conversations, or imagined? How many, and did you resist pitching?
- Were answers about the hardest step consistent? Different answers suggest no coherent group.
- Did you write the token-free 300-word description? Does it still justify existence?
- Is the twelve-month replacement a concrete plan or a small beta?
- Does validation have failure criteria? Without them, every outcome seems promising.
- Which question are you avoiding most?
Most people are stuck at step one while believing it is step three. Name three real users, their features, and last week's complaints. If you cannot, later discussions lack a foundation.
These six answers form the “is this worth building?” section of the capstone.
Key idea
Prove people will use it without a token before deciding whether to issue one.