Week 1
The Idea
Mine the day job for boring problems that are close enough to understand and specific enough to sell.
Source
Start where you already have taste.
The best first idea is usually a small workflow problem from a job, industry, hobby, or recurring obligation the member already understands.
Domain context is the unfair advantage. A non-coder who has lived the messy workflow can often specify a better thin product than a programmer guessing from the outside.
Reject abstract app ideas until they are attached to a real user, real job, and real before-and-after. If the sentence starts with everyone who wants, it is too broad.
Good first problems are boring: weekly reporting, intake cleanup, document review, quote preparation, onboarding checklists, internal calculators, client follow-up, or a spreadsheet that everyone complains about.
Inventory
Mine recurring pain, not inspiration.
The first pass is a problem dump. List tasks that repeat, handoffs that break, questions people answer over and over, and places where employees paste the same thing between tools.
Score each candidate by pain, frequency, buyer access, specificity, and whether a thin build could help by Friday. You are not looking for the biggest market. You are looking for the first reachable proof.
A promising idea has a named person, a current workaround, a moment of urgency, and a clear smaller version. If you cannot name the current workaround, you do not understand the problem yet.
Validation
Five conversations beat a survey.
Members ask about the problem, current workaround, urgency, and willingness to try a rough solution.
They do not pitch until they have heard the existing pain in the user's words. The conversation is not a sales call; it is a search for repeated language.
Useful questions are concrete: when did this last happen, what did you do, how long did it take, what made it annoying, who else cares, and what would a rough fix need to do before you would try it?
Compliments are weak evidence. Calendar time, a forwarded example, a request to see the prototype, a willingness to introduce another user, or a clear current workaround is stronger evidence.
Narrowing
Turn the idea into one thin promise.
The first promise should describe a before-and-after, not a feature pile. For example: turn messy intake emails into a clean job brief, or turn a long call transcript into a follow-up checklist.
The thin version should serve one user path: input, action, output, save or share. Anything outside that path is a future note, not a Week 1 requirement.
Name the exclusions early. No team accounts, no complex permissions, no automated billing, no perfect dashboard, no integrations unless the first user cannot get value without them.
Gate
Choose with evidence, not excitement.
Build only after the idea survives the evidence gate: at least five conversations, one repeated pain pattern, one reachable first user, and one thin version that can be manually supported.
If the evidence is weak, narrow the buyer or problem before opening the harness. Building too early feels productive but usually creates a demo nobody asked for.
The output of Week 1 is not certainty. It is a defensible bet small enough to build and specific enough to test.
Choose one boring problem
- List ten recurring problems from work or adjacent professional life.
- Score each by pain, access to buyers, and ability to ship a thin first version.
- Pick the top three and write the current workaround for each.
- Have five short conversations before pitching a solution.
- Capture exact customer phrases, objections, current tools, and examples.
- Choose one problem and write the first product promise in one sentence.
- Define the first thin user path and three things you will not build yet.
Prompt starters
- List ten recurring problems from my job or adjacent professional life. For each, name the user, current workaround, frequency, pain, and a tiny useful version.
- Turn this vague idea into a narrow before-and-after promise for one reachable buyer. Challenge assumptions and ask what evidence is still missing.
- Create five validation questions that ask about current behavior, not opinions about my idea.
- Summarize these conversation notes into repeated pain, exact customer language, weak evidence, strong evidence, and the narrowest buildable promise.
- Help me decide build, narrow, or discard using pain, frequency, buyer access, specificity, and thin-build feasibility.