Founder Playbook · The Bootstrapped Founder
5 tactics from Arvid Kahl
Focusing on Customer Retention Features
Watch the full episode“Okay Cupid... used to be a pretty complex product that made it possible to find very interesting romantic matches... over time it devolved into something more like Tinder a pretty simple swiping app that does not create deep connections... they had to cater not to the existing users but to their growth metrics to get new people”
Beware the marginal-user trap — chasing the next signup degrades the current user
When a product grows, the next signup is statistically less sophisticated than the last one — and growth-team incentives push you to optimize for them. OkCupid started as a deep-questionnaire matchmaker and became a Tinder-like swipe app because each new cohort needed simpler UX. Every feature you simplify for the marginal user nudges power-users toward the door. Catch yourself before you ship the third "make this easier" feature in a row.
“the highest chance of feature adoption and customer retention comes from features that align with the job that the customer needs to do with the tool... features that did something outside that scope were often ignored and complained about like we considered integrating other systems that they may have used or building communication features between teachers but those things were underused or unused at all”
Build only features aligned to the specific job-to-be-done your tool exists for
Audit every feature request against the single job your tool solves. FeedbackPanda existed to help teachers ship written student feedback faster. "Communicate with other teachers" sounded reasonable but had zero adoption — outside the job. "Share feedback templates across teachers" sat directly inside the job and exploded adoption + network effects. The pull to add adjacent features is always there; the discipline is to refuse anything that doesn't make the core job faster or easier.
“any feature that makes this easier is a strong candidate to be built early so for inputs just look for features that add ways to connect and make connection easier to the things that come before and for outputs add new formats that follow-up tasks expect or can deal with more easily”
Prioritize features that improve workflow inputs and outputs over standalone ones
Your tool lives inside a chain of other tools — what comes before, what comes after. Features that improve the join between your tool and the upstream/downstream steps compound the most. Import filters and integrations for inputs; new export formats (SRT subtitles, CSV, API webhooks) and enrichments for outputs. Standalone bells-and-whistles that don't touch the workflow boundary almost always underperform integrations.
“sometimes customers say they will join if you build a particular feature if possible make them commit by paying for multi-month subscription with the guarantee that you built the feature within a reasonable time frame otherwise them telling you that they will sign up if you build this that's just an empty promise”
Force "I'll sign up if you build X" prospects to pre-commit with a multi-month plan
"Build X and I'll sign up" is one of the most expensive lies in early product development — you build the feature, they don't convert, and you're stuck maintaining bloat for one phantom prospect. Convert the conversation: "I'll build X if you prepay 6 months at full price, refundable if I don't ship by date Y." Real prospects pre-commit; tire-kickers go quiet. Either way you stop building features for non-customers.
“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.