Find the Signal
Most app ideas start in the wrong place. They start with the solution — "I want to build an app that does X" — before the problem is understood. This produces apps that solve the wrong problem elegantly, or the right problem for nobody in particular.
The better starting point is a signal. A signal is a recurring friction in your work or the work of people you know. The spreadsheet someone rebuilds every week. The manual step that interrupts an otherwise automated process. The decision made on instinct because the data is too hard to pull together. The information that exists in one place but needs to be in three others.
Signals are not ideas. They are observations that have not yet been turned into anything. Your job in this mission is to find one worth turning into something.
List the frictions
+10 XP→ Open a notes app, a Google Doc, or a blank piece of paper → Set a 15-minute timer → Write down every repeating frustration you can think of in your work or business — processes that feel manual, slow, error-prone, or invisible → Don't filter. Write anything that comes to mind, even if it seems too small
Aim for at least 10 items. The first 5 will be obvious. The next 5 are where the real ideas usually are.
* *"I had three ideas in the first five minutes. By minute twelve I'd written down the one that actually became the product. The obvious ideas weren't wrong — they just weren't mine."*
"I want to find a problem worth building an app for. I work in [describe your field or role]. Ask me 10 questions to help me surface recurring frustrations or inefficiencies I might not have noticed."
Narrow to one
+10 XP→ Read back your list → Ask three questions about each item: — Does this happen more than once a week? — Would solving it save time, money, or errors? — Is this a problem you understand well enough to explain to someone else in five minutes? → Mark the items that score yes on all three → Pick one. If more than one qualifies, pick the one that would embarrass you most to still be doing manually in two years.
One idea. Not two. Not "either of these." One.
* *"I picked the second one on my list, not the first. The first felt more impressive. The second was the one I actually needed."*
"I've narrowed my app idea to these options: [list them]. I need to pick one to build over 26 weeks. Ask me questions to help me choose the one most worth building."
Write the problem statement
+10 XP→ Create a new file called mission-brief.md
→ Add a section called The Problem
→ Write one paragraph — 3 to 5 sentences — describing the problem you chose:
— What is the situation?
— What happens currently — the manual process, the gap, the friction?
— What does that cost — in time, money, errors, or missed opportunity?
Don't describe the solution. Describe only what is currently broken.
Example:
"Our sales team manually exports leads from the CRM every Friday afternoon, copies them into a spreadsheet, and shares it with three people over email. Each person then reformats the data differently before using it. This takes two hours per week and regularly results in different versions of the same report being discussed in the same meeting."
* *"Writing the problem statement took me forty minutes. Not because it was hard — because I kept describing the solution instead. Once I stopped describing what I wanted to build and described only what was currently broken, it wrote itself in five minutes."*
"Help me write a clear 3–5 sentence problem statement for this situation: [describe it]. It should describe what currently happens, not what I want to build."