Project Problem and Use Case

Learning objectives

• Define the user problem before analysing the proposed blockchain solution.
• Test whether blockchain, a token or decentralisation is necessary to solve that problem.
• Separate genuine user value from narrative, subsidy and speculative demand.

What it is

The problem statement should identify a user, a pain point and the cost of the status quo. “Payments are inefficient” is too broad; “cross-border freelancers wait three days and lose 4% to fees and FX” is testable.

A use case describes who uses the product, what action they take, why the action is better than the alternative and what must be true for the behaviour to persist. Good research writes this down before reading token-price commentary.

Blockchain can add censorship resistance, composability, transparent settlement or shared state, but it also adds wallet friction, irreversible errors, smart-contract risk and often variable fees. The burden of proof is therefore comparative, not ideological.

How to analyse it

Start with the existing workflow and identify where value is lost through cost, delay, trust, access or coordination. Then test whether the proposed protocol removes that bottleneck or merely relocates it.

Distinguish users from token holders. A project can have active traders but few product users, or many subsidised users whose activity disappears when incentives stop. Product demand should be measured in the unit that reflects the actual service delivered.

Test necessity. If the same service works equally well with an ordinary database and a regulated payment provider, the token may be primarily a financing or incentive layer rather than an essential product component. That may still be investable, but it changes the thesis.

Finally test willingness to pay. Usage that produces no durable economic value can inflate transaction counts without proving product-market fit. Fees, repeat behaviour, retention and off-chain substitutes help distinguish utility from activity theatre.

Research framework

Evidence hierarchy and limitations

Use primary evidence where possible: product documentation, live transaction flows, fee schedules, user cohorts, independent customer interviews and competitor pricing. Social engagement and token-holder counts are secondary evidence because they do not prove the problem is being solved.

Beware denominator games. A project may report millions of “transactions” that are automated, batched or economically trivial. Translate headline activity into users, value transferred, revenue and repeat usage before concluding that the use case is strong.

Worked example and thought exercise

Common mistakes and practical workflow

• Starting with the token rather than the user problem.
• Assuming decentralisation is automatically a user benefit.
• Using transaction count without economic context.
• Ignoring incumbent solutions and switching costs.

Practical workflow

1. Write the user, problem and existing workaround in one paragraph.
2. Quantify the status-quo cost, delay or risk.
3. Compare the proposed solution with at least two realistic alternatives.
4. Test whether crypto architecture is necessary or merely optional.
5. Verify repeat usage and willingness to pay before linking product adoption to token value.

Knowledge checkpoint

1. What makes a problem statement testable?
2. Why are token holders not the same as product users?
3. How can blockchain relocate rather than remove trust?
4. Which metrics best test willingness to pay?

FAQs

Summary

Project research starts with the problem, the user and the incumbent alternative. Only after those are clear should an analyst decide whether blockchain architecture improves the workflow and whether any resulting product value can plausibly support the token thesis.