The Problem
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. That produces apps that solve the wrong problem elegantly, or the right problem for nobody in particular.
The better starting point is a signal: 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 scattered to pull together. Signals aren't ideas yet — they're observations you haven't turned into anything. Your job this mission is to find the one worth turning into something, and write down what's actually broken.
This is also where the Superpowers plugin enters. You'll install it, then use its brainstorming skill in Chat to surface frictions you might not have noticed — before you commit a single word to the brief.
Install Superpowers and list the frictions
+10 XP→ Open Claude Code and run /plugin install superpowers@claude-plugins-official — this is the one install this week; Claude Desktop and the Skilled Rabbit connector are already set up from onboarding
→ Open a Chat, set a 15-minute timer, and use the brainstorming skill to surface every repeating frustration in your work — processes that feel manual, slow, error-prone, or invisible
→ Don't filter. Write down anything that comes to mind, even if it seems too small. Aim for at least 10 items
→ Note where the brainstorming skill pushed you past the obvious first five
Where you work: Code (install) → Chat (brainstorming skill)
Time: ~25 minutes
Finney's Nudge New to surfacing frictions? Open a Chat and use the brainstorming skill with this:
"I want to find a problem worth building an app for over the next 26 weeks. I work in [describe your field or role]. Ask me 10 sharp questions, one at a time, to surface recurring frictions or inefficiencies I might not have noticed — don't propose solutions yet."
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. The brainstorming skill kept asking 'and what happens right before that?' until the real one fell out.
Narrow to one
+10 XP→ Read back your list and ask three questions of each item: Does this happen more than once a week? Would solving it save time, money, or errors? Do you understand it well enough to explain it to someone 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 by hand in two years → Write the chosen one at the top of a fresh note — this is your candidate
Where you work: Chat
One idea. Not two. Not "either of these." One.
Time: ~15 minutes
Finney's Nudge Torn between options? Ask in Chat:
"I've narrowed my app idea to these options: [list them]. I need to pick one to build over 26 weeks. Ask me questions — one at a time — to help me choose the one most worth building. Don't choose for me."
I picked the second one on my list, not the first. The first felt more impressive. The second was the one I actually needed. Impressive is for the pitch; needed is for the build.
Write the problem statement
+10 XP→ Open Cowork and create a new file called mission-brief.md
→ Add a section titled The Problem and write one paragraph — 3 to 5 sentences: What is the situation? What happens currently — the manual process, the gap, the friction? What does it cost, in time, money, errors, or missed opportunity?
→ Read it back. If it describes the solution anywhere, cut that sentence — this section describes only what is currently broken
→ Let it land: you now have a problem on paper that was a vague annoyance an hour ago
Where you work: Cowork
Time: ~15 minutes
Finney's Nudge Keep slipping into describing the solution? Ask in Chat, then write the result into Cowork:
"Help me write a clear 3–5 sentence problem statement for this situation: [describe it]. It should describe what currently happens and what it costs — not what I want to build. Flag any sentence that drifts into describing a solution."
Writing the problem statement took me forty minutes — not because it was hard, but because I kept describing the solution instead. Once I stopped describing what I wanted to build and described only what was broken, it wrote itself in five minutes.