When to use it
A project has changed direction several times, or you’re about to start one, and you want a grounded recommendation instead of a brainstorm.
Lead brief
Task: research only. Do not change code, deploy, or touch DNS.
1. Read everything about <PROJECT>: docs/, READMEs, git history. Write a timeline:
each positioning, how far it got, why it changed.
2. Check the current state: is it live, where is it hosted, does the backend run?
3. List our real capabilities (what is in production today, not what was planned).
4. Scan the market with web search: competitors, pricing, funding/revenue signals, gaps.
Mark vendor-reported numbers as such.
5. Give 2–3 options. For each: target user, pain, 4-week MVP using existing capabilities,
pricing, competitors and our difference, risks, domain plan.
6. Recommend one, with reasons, and list the decisions only the owner can make.
Write it to docs/<NAME>.md and commit.
Splitting the work
For a wide scan, the lead can hand each researcher one market segment and merge their notes. Keep researchers read-only; they only write notes.
Done when
- The timeline explains every pivot with evidence from the repo
- Every market claim has a source link
- The recommendation ends with a short, numbered list of owner decisions
Lessons from real runs
- The most useful finding is often what you already run in production for another project. Recommend from that, not from the most exciting market.
- Ask the lead to separate “facts we checked” from “estimates” explicitly; market data in this space is mostly self-reported.