Make your story easier to understand.
A practical guide to describing a project with context, evidence, and honest unknowns.
Describe what you know, how you know it, and what still needs to be tested. Clear limits make a claim more useful.
Begin with the problem and the people
Describe who experiences the problem and what they do today. Explain the local conditions that an outside reader may not know: distribution, infrastructure, seasonality, language, or the way customers make decisions.
Keep the description specific to your own experience. If you are describing a hypothesis rather than something observed, call it a hypothesis. You do not need to make your project sound larger to make its purpose understandable.
Separate evidence from ambition
A customer interview, a prototype test, an active user, a signed contract, and collected revenue each tell a different story. Use the description that matches what happened, with a date or period where helpful.
For example, an illustrative statement such as 'we interviewed 12 shop owners in June' communicates a different level of evidence from '12 shops are paying customers.' This example is guidance, not a claim about a FirstContact participant.
- Identify the source and date of a factual claim.
- Define a metric before comparing it across periods.
- Separate targets and forecasts from observed results.
- Share only information you have permission to disclose.
Explain the next step
State what you want a conversation to help resolve. That might be understanding fit, receiving feedback, exploring a partnership, or discussing a capital need. Explain what progress would look like and what remains uncertain.
Avoid treating every kind of support as interchangeable. The capital lifecycle research explores the broader product direction; it does not mean every funding or ownership pathway is available through FirstContact today.
Review what another person will see
Private intake context and a public-facing listing serve different purposes. Before sharing a profile or approving an introduction, read it as a recipient would: can they understand the claim, its evidence, and the request?
Remove unsupported superlatives, private third-party information, and numbers you cannot explain. A draft can be polished without adding facts. Approval should apply to the actual version being shared.