Founder Playbook
Product
“is it a job to be done that you're currently solving does it fit the scope of the problem that you're trying to solve is it part of a workflow and does it improve integration into existing processes does it change or simplify input methods or is it enhancing your output adding new ways to export results... the more of these criteria your feature fits the more likely is that you should go ahead and build it”
Run every feature request through this 5-question filter before you build
Before any feature gets on the roadmap, check it against 5 yes/no questions: (1) does it serve the core JTBD I'm solving? (2) does it stay inside the scope of my product's promise? (3) is it part of the customer's workflow? (4) does it improve a workflow input or simplify a connection? (5) does it improve a workflow output or enrich downstream-tool integration? 3+ yes = build it. 0-1 yes = decline politely. This single checklist will kill 80% of incoming feature noise.
A
Arvid Kahl
The Bootstrapped FounderSolo essay on the "tyranny of the marginal user" — why indie founders should build retention features around the jobs-to-be-done workflow, not chase next-user simplicity.
The Bootstrapped Founder
Focusing on Customer Retention Features· 10:00