Write a brief worth diagnosing
Everything downstream — the verdict, the signals, the MVP model — is only as sharp as what you describe up front. Two minutes here makes the rest of the workflow noticeably better.
A good brief covers four things:
- The problem, not the solution. Describe the situation that hurts before you describe what you would build.
- Who has it. A specific person in a specific role, not “everyone” or “small businesses.”
- How they handle it today. The spreadsheet, the workaround, the tool they pay for and complain about.
- What makes you unsure. Naming your own doubt tells Scoutr which assumption to stress-test first.
“An app that helps people count calories.”
“An app for people who want to lose weight but drop calorie-tracking apps within two weeks, because logging every meal by hand is too tedious. Today they try MyFitnessPal and quit. I'm not sure the real blocker is the food database or the discipline of logging at all.”
You don't need polished prose. Scoutr reads natural language and detects whether you're writing in English or Spanish from the text itself.