N2 · Crypto Product
Relearn product design under irreversibility, signatures, and composability. Deliver a PRD and clickable prototype including failure paths.
This track serves product managers, designers, and career changers.
Its premise comes from Chapter 27: this is a product with fundamentally different constraints. Familiar workflows fail because their assumptions no longer hold. Make these three constraints your default starting point.
Who This Track Serves
Look at your current work rather than your title.
After years in Web2, your first onchain assignment makes familiar tools fail. Prechecks, staged releases, rollback, and customer-service refunds either do not exist or have different costs. You sense a gap without knowing what is missing.
Your onchain PRDs repeatedly miss failures exposed after launch. Clicks do nothing, users click three times, displayed success precedes receipt, or an incomprehensible popup gets signed. Documentation always follows problems.
Your design stops at the wallet popup. The most important confirmation occurs in an interface you cannot control, where your design ends.
You can prototype but cannot explain how onchain products differ. Asked what happens when a step fails, you have no concrete response.
If you hope to hide all onchain complexity, expect discomfort. Only some can be hidden; the rest must be explained.
Prerequisites
Eight Part A chapters are required: three establish your worldview; five provide working methods.
| Required chapter | Role here | Consequence of omission |
|---|---|---|
| Chapter 5 · Who Owns Crypto? | Keys, signatures, custody | Become a custodian without recognizing it |
| Chapter 6 · An Onchain Transaction | Finality as a progression | Show success at inclusion |
| Chapter 9 · Smart Contracts | Composition, upgrades, permissions | Treat integration as exceptional |
| Chapter 20 · Tokenomics | Incentives as product rules | Reward unwanted behavior |
| Chapter 23 · Onchain Data | Independent metrics and six measurement questions | No meaningful launch metrics |
| Chapter 27 · Crypto Product | This track's backbone: three constraints, six states, ten failures, four signature types | No framework for later work |
| Chapter 28 · Crypto Growth | Retention cannot be purchased | Incentivize a product unable to retain people |
| Chapter 30 · Finding PMF | Four signals after removing subsidies | Mistake subsidy curves for demand |
Why these eight? Main flows depend on 6 and 27, signatures on 5 and 27, composition on 9, incentives on 20 and 28, and acceptance metrics on 23 and 30.
Complete one Lab genuinely: screenshot a DApp's first-use flow in Chapter 27. Especially inspect and revoke your approvals at the end. Doing this changes your authorization defaults.
What You Will Learn
Ten topics form five groups. Their order follows a feature from idea to launch.
- Identify the user
- Mechanisms are product rules
- Interfaces under three constraints
- Validation and growth
- AI in products
| Group | Topics | Problem addressed | Connecting chapters |
|---|---|---|---|
| Identify the user | Market Research, User Research | Whose problem is solved and how you know | 25, 30 |
| Mechanisms are product rules | Protocol Logic, Tokenomics | How underlying rules constrain interface choices | 9, 20 |
| Interfaces under three constraints | Wallet UX, PRD | Requirements under irreversibility, signatures, composition | 27 |
| Validation and growth | PMF, Growth, Analytics | Useful metrics without subsidy distortion | 23, 28, 30 |
| AI in products | AI Product | Delegable tasks and boundaries | 31, 32, 34 |
Three Things to Relearn
Mechanisms are the group Web2 product managers most readily skip, with the greatest consequences. Backend details cannot simply be delegated: protocol rules are product rules. Liquidation thresholds, fee allocation, parameter authority, and upgrades directly determine interface choices, warnings, and prohibitions. Without understanding liquidation, you cannot write lending risk messages.
Interfaces must preserve informed consent rather than merely shorten flows. Bundle signatures while bounding approval amounts and expiration and translating their meaning in your own interface. Fewer clicks must not reduce understanding. Apply all six transaction states, ten failure paths, and four signature categories whenever writing transaction requirements.
Set AI boundaries before features. Explanation—translating calls or summarizing documentation—and execution—deciding actions or moving funds—have different error costs: misleading information versus money. AI's Role in Crypto OS's capability levels and Chapter 34's permission table are required PRD sections.
Chapter 27's ten failures: missing native tokens, insufficient balance, inadequate approval, excessive slippage, front-running, pending mempool transaction, contract failure, user cancellation, congestion, and reorganization.
It is mandatory in every PRD. Seven can be blocked before signing; pre-signature checks have exceptionally high returns.
Models writing onchain PRDs systematically omit this section—their learned templates lack it. Humans must supply the checklist.
The attention users spend understanding approvals, and the interface space and steps needed to convey them.
This differs from interaction cost. A common error is reducing interactions by reducing understanding: bundling three signatures without explaining their contents.
Test the boundary: would a user feel deceived after discovering what they approved? If yes, saved clicks were borrowed from informed consent.
Final Deliverable
A complete PRD and clickable prototype covering signatures, failures, and revocation.
Signatures, failures, and revocation are the primary assessment areas. Anyone can draw the successful flow.
Distinguish this from the Capstone Project. The technical capstone proves a working system can be built. Here implementation is optional, but every unfavorable path must be designed, demonstrating understanding of real-world failures.
Five acceptance criteria:
All six states have interfaces and copy, with the success state and criterion specified.
Construction, awaiting signature, broadcast, awaiting confirmation, confirmed, and final: omit none. Pending confirmation shows count and threshold. Premature success fails this criterion.
For every failure, specify trigger, exact user-facing copy, and product action.
“Show a friendly message” is not copy. Mark failures prevented before signing—their number measures PRD quality.
Every signature specifies type, amount, expiry, and a plain-language explanation in your interface.
Distinguish transfer, approval, message, and offline order. Approvals use needed amounts and expiry, with inspection and revocation of prior approvals. Unlimited defaults fail.
Failure paths must be clickable in the prototype.
Demonstrate at least missing native tokens, wallet cancellation, and a transaction stuck in the mempool. A happy-path-only prototype misses the track's purpose.
Include a page explaining unavailable undo actions and a launch-observation plan.
Explain expected reversals, why they are impossible, and preventive substitutes. Specify three post-launch metrics, definitions, and retention depth. These pages connect product and research capability.
Assess Your Readiness
Ready: identify each signature category, amount, expiry, and worst possible loss.
Not ready: conflate transfers and approvals, cannot specify allowance, or choose unlimited authority unconsciously.
Chapter 27's rule: a feature should not launch unless it states the worst outcome after signing and who bears the loss.
Ready: approximately seven, with mechanisms such as balance checks, allowance checks, simulation, and input limits specified individually.
This improves retention, losses, and support workload together. Avoiding a doomed transaction saves both fees and frustration.
Not ready: every failure receives only an after-the-fact message. Web2 failures are often free; failed onchain transactions still charge fees.
Ready: Chapter 28's third or fourth layer—non-incentivized paid interactions or users returning after campaigns—rather than active addresses. Explain data collection and definitions.
Not ready: first-layer counts or usage totals, both easily inflated by incentives.
Another overlooked metric: first-use completion rate, directly reflecting failure-path quality.
Ready: inspect address-versus-person limits, bulk-call risk rules, aggregators counted as users, and consequences when interface checks are bypassed.
This tests the third constraint. Chapter 27 described a protocol assuming human callers, its own interface, and one operation at a time; integration invalidated all three.
Put “Does this assumption hold for a programmatic caller?” in your PRD checklist.
No standard answer; check:
- Is state copy exact wording, rather than descriptions like “show loading”?
- Are any failure actions impossible, such as automatically retrying and refunding gas?
- Do approvals have concrete amount and expiry rules, rather than merely “as needed”?
- Can the engineer click failure paths?
- Are differences across three mainstream wallets addressed?
- Does the engineer know where to instrument each metric?
Have someone draw the transaction state machine using only the PRD, without questions. Differences reveal gaps most likely to become incidents.
Common Mistakes
Mistake one: treating it as Web2 with wallet login.
Copied funnels, staged releases, and support workflows require patches wherever assumptions fail.
The constraints are the environment rather than features. Before designing, ask whether errors can be corrected, servers can act for users, and interfaces and callers are controlled. Three negative answers invalidate familiar workflow premises.
Mistake two: filling product gaps with tokens and incentives.
Poor retention receives points; poor conversion receives airdrop expectations. Numbers improve immediately.
Chapter 28 explains incentives buy first use, while products earn retention. Money buys the first four layers, never the fifth. A zero fifth layer makes stronger acquisition a steeper cliff.
Establish retention before purchasing acquisition. Product budgets often belong in slow, hard-to-attribute improvements: subsidizing the first fee, fixing failures, and bundling signatures.
Mistake three: prototyping only happy paths.
Reviews run smoothly; support problems appear outside the demonstration.
Unfavorable paths are routine onchain: fees, allowance, slippage, and canceled popups occur daily and cause real churn or loss.
Demonstrate three failures before the main flow. This immediately exposes weak design.
Mistake four: using user counts as demand evidence.
An upward curve during an incentive campaign is treated as feature approval.
Chapter 30 shows subsidies can fake every Web2 PMF signal, including volume, retention, organic growth, and paid conversion.
Remove subsidies and inspect self-funded retention, willingness to pay, organic sources, and retention depth. Depth is hardest to fake: keeping personal funds in a contract for a week means more than a hundred clicks.
Next Steps
Do two exercises: Chapter 27's screenshots including approval inspection, and Chapter 30's five real conversations. One trains defaults; the other grounds requirements in evidence.
Complete the Capstone Project's Crypto Research OS. Independent data skills underpin post-launch observation rather than merely adding polish.
Read two AI foundations: AI's Role in Crypto OS for capability levels and safety, and Chapter 34 for permissions. Begin any model-with-funds requirement there.
Compatible tracks:
| Combination | Why it fits |
|---|---|
| N3 · Crypto Growth & Operations | Product owns the fifth funnel layer, growth the first four. Shared metrics prevent blame-shifting |
| N1 · Crypto Research & Investment | Observation requires research; independent data improves competitor assessment |
| N5 · Crypto Founder | A founder's first document is this deliverable plus token-necessity analysis |
To implement your prototype, follow T1 · EVM Engineer, T13, and T14, where signature and state-handling details become concrete.
N1 · Crypto Research & Investment
Collect your own data, build your own valuations, and deliver sector research others can verify. This track teaches methods rather than trading advice.
N3 · Crypto Growth & Operations
Replace successful-campaign claims with reproducible retention curves. Explain what your spending bought after incentives stop.