Scope & features

About 50 episodes discuss scope, and the dominant view is ‘do one thing phenomenally’. Guests such as Jonathan Fishner (‘start with a wedge, not the full vision’), Louis Pereira (AudioPen does one thing very well), Yasser Elsaid and Shaan Arora say winners have one core feature; Pat calls these ‘pointy’ apps and claims every successful app on the channel is simple (a host generalisation). MVPs should be stripped down (Abhishek’s Typeform alternative shipped with basic fields and CSV export), though Lane Wagner warns MVP means ‘minimum quantity’, not minimum quality. On what to add, guests split: Julien Nahum has ‘only built what people ask’, while others treat feedback as a signal to filter by persona, repetition and usage data (Rob Hallam: if nobody raises it again, it wasn’t important; he even killed a viral but unused feature). After launch, several founders freeze features to focus on distribution (Mau Baron: ‘do not touch your app’) or reliability (Nevo: winners ‘don’t break’), whereas prolific shippers like Marc Lou keep releasing constantly. Cautionary tales include five years building features for zero customers and a four-month rebuild once a team learned users wanted answers, not tools.

Key points

• Build one core feature and do it phenomenally; start with a narrow wedge — 11 episodes. (CJ Zafir · CJ Zafir (May 2025) ▶ 02:19) (Jonathan Fishner · Jonathan Fishner (Feb 2026) ▶ 12:15) (Yasser Elsaid · Yasser Elsaid (Jul 2025) ▶ 07:48) +7 more
• Build what paying users ask for, quickly, rather than your own ideas — 7 episodes. (Julien Nahum · Julien Nahum (Nov 2024) ▶ 10:34) (Gaurav · Gaurav (Aug 2026) ▶ 09:02) (Nic · Nic (Feb 2026) ▶ 07:55) +4 more
• Ship a stripped-down MVP: minimum quantity, not minimum quality — 7 episodes. (Abhishek · Abhishek (Aug 2025) ▶ 06:25) (Sebastian Röhl · Sebastian Röhl (Jun 2025) ▶ 03:00) (Leandro · Leandro (Jun 2025) ▶ 07:26) +4 more
• Filter requests by persona, repetition and usage data; drop features people don’t use — 6 episodes. (Jozef Gherman · Jozef Gherman (Jul 2024) ▶ 10:06) (Rob Hallam · Rob Hallam (Aug 2026) ▶ 05:21) (Lane Wagner · Lane Wagner (Apr 2025) ▶ 05:29) +2 more
• After launch, stop adding features: put effort into distribution or reliability — 6 episodes. (Mau Baron · Mau Baron (Jan 2026) ▶ 12:11) (Nevo · Nevo (Jul 2026) ▶ 10:17) (Jake Glacer · Jake Glacer (Jul 2026) ▶ 15:24) +3 more
• If the product itself is wrong, pause and rebuild around what users actually want — 3 episodes. (unnamed guest · Eyal & Yahli (Nov 2025) ▶ 04:03) (David Park · David Park (Jan 2024) ▶ 05:45) (Loïc Berthelot · Loïc Berthelot (Nov 2025) ▶ 02:52)
• Favour business features and low-maintenance simplicity over engineering for its own sake — 3 episodes. (Samuel Rondot · Samuel Rondot (Jul 2025) ▶ 04:49) (Angus Cheng · Angus Cheng (Jul 2025) ▶ 06:39) (Jay · Jay (Sep 2026) ▶ 04:27)

Where guests agree

• Start narrow: one problem, one persona, one core feature (CJ Zafir · CJ Zafir (May 2025) ▶ 02:19) (Jonathan Fishner · Jonathan Fishner (Feb 2026) ▶ 07:56) (Lane Wagner · Lane Wagner (Apr 2025) ▶ 05:07) +3 more

Where guests disagree

Should you build what users ask for? ⚠️

• Yes: only build what customers request, and ship it fast (Julien Nahum · Julien Nahum (Nov 2024) ▶ 10:34) (Nic · Nic (Feb 2026) ▶ 07:55)
• Treat requests as signals, not a backlog: judge by persona, repetition and quality (Jozef Gherman · Jozef Gherman (Jul 2024) ▶ 10:12) (Rob Hallam · Rob Hallam (Aug 2026) ▶ 05:21) (Mauro Botanes · Mauro Botanes (Sep 2026) ▶ 05:32) +1 more

After launch, keep shipping features or freeze the product? ⚠️

• Freeze: don’t touch the app, obsess over distribution or reliability (Mau Baron · Mau Baron (Jan 2026) ▶ 12:11) (Nevo · Nevo (Jul 2026) ▶ 10:10)
• Keep shipping frequently from user feedback (Marc Lou · Marc Lou (Apr 2026) ▶ 07:31) (Ania Wysocka · Ania Wysocka (Aug 2025) ▶ 10:08)

Frameworks

• Three phases of deciding what to build — How Symmetry’s approach to product decisions evolved. (Mauro Botanes · Mauro Botanes (Sep 2026) ▶ 05:32)
  • Build what we wanted (terrible idea)
  • Build what users asked for from feedback (mediocre)
  • Methodical, scientific experimentation
• Product-led growth (PLG) — Self-serve model: marketing off-site, landing page plus Stripe checkout, one core feature, good UI, no bugs. (Yasser Elsaid · Yasser Elsaid (Jul 2025) ▶ 07:40)
  • Stripe button on the website
  • Marketing done outside the website
  • Good landing page
  • One core feature
  • Good UI and no bugs
• Lean MVP loop: ship small, get feedback, iterate or move on — Angus’s approach to building products. (Angus Cheng · Angus Cheng (Jul 2025) ▶ 03:08)
  • Make an MVP and launch as quickly as possible
  • Get it in front of your target audience, not friends and family
  • Build features based on real user feedback (emails, analytics)
  • Stop working on features people don’t use
• Developer-tool playbook (five steps) — Jonathan’s steps for starting a developer tool from idea to business. (Jonathan Fishner · Jonathan Fishner (Feb 2026) ▶ 07:01)
  • 1. Be the user / build for yourself
  • 2. Design for the persona’s constraint, not the ideal (developers: self-hosted, no sign-up, no credentials)
  • 3. Start with a wedge, not the full vision; iterate in small steps
  • 4. Let usage lead monetisation (e.g. team real-time collaboration)
  • 5. Market where the ICP lives (GitHub, Hacker News, self-hosted subreddits)

Tactics

• Build only the highest-ROI, easiest feature first — Pick one feature, make it functional and get it to users as fast as possible. (Hassam · Hassam (Jan 2026) ▶ 09:50)
• Ship a stripped-down MVP in two weeks — Basic fields, CSV export, no integrations, no logo or fancy landing page. (Abhishek · Abhishek (Aug 2025) ▶ 06:25)
• Pick the next feature by impact and personal happiness — Keep a running list from user feedback; after each release, choose what has most impact on users and would make you happiest. (Marc Lou · Marc Lou (Apr 2026) ▶ 05:49)
• Prune your to-do list by copying forward only what matters — When a note list gets too long, start a new note and copy over only the important items; unrepeated requests drop away. (Rob Hallam · Rob Hallam (Aug 2026) ▶ 05:19)
• Use analytics to find drop-off points — If people drop off on a page, work on it; if a feature isn’t used, stop developing it. (Angus Cheng · Angus Cheng (Jul 2025) ▶ 03:26)
• Freeze features to stabilise — He stopped shipping new features so that all 30 social channels work reliably. (Nevo · Nevo (Jul 2026) ▶ 10:10)
• Give users the answer instead of a tool — They switched from letting users input and check bets to giving pre-analysed picks (‘the right answers to the test’). (unnamed guest · Eyal & Yahli (Nov 2025) ▶ 04:03)
• Pause marketing and rebuild when the product is wrong — They shut down marketing and spent four months on engineering and design, then relaunched into a seasonal peak (NBA playoffs). (unnamed guest · Eyal & Yahli (Nov 2025) ▶ 04:12)
• Ship a privacy-first MVP with no sign-in — Store all data locally, no authentication; keep just core tracking and visualisation. (Sebastian Röhl · Sebastian Röhl (Jun 2025) ▶ 03:00)
• Choose between new features and simplifying existing ones — Constantly weigh building a much-requested new feature against making an already-built feature easier. (Anton · Anton (Nov 2025) ▶ 06:21)

Stories & examples

• Killing a viral feature: The algorithm simulator feature went viral on X but most people did not use it, so he removed it from SuperX. Lesson: Kill what doesn’t work even if it went viral. (Rob Hallam · Rob Hallam (Dec 2025) ▶ 14:14)
• Five years building in the dark: His first five working years went into a SaaS with many features and zero customers or revenue, making every bad decision possible. Lesson: Building features without users wastes years. (Loïc Berthelot · Loïc Berthelot (Nov 2025) ▶ 02:52)
• Breaking a $2,000 plateau by talking to users: Stuck at $2,000 a month, they asked users harder questions about workflow and dislikes, learned people wanted a friendly AI-assisted writing journey, stripped everything else and started to grow. Lesson: Deep user research can reveal what to cut. (David Park · David Park (Jan 2024) ▶ 05:45)
• The super brain Reddit post: They posted a demo of the newly launched super brain feature without knowing if it was useful; it drew positive feedback and feature requests and became the main feature thousands use. Mods later started removing such posts. Lesson: Reddit feedback can validate and shape a feature. (Ayush · Ayush (Jan 2026) ▶ 07:33)

Numbers

• Features a simple app needs: 1-3 features (self-reported, approx.) (Connor Burd · Connor Burd (Oct 2025) ▶ 12:35)
• Features shipped on his marketplace in the last 3 months, and new apps in 2026: 300 features; 6 apps count (self-reported, approx.) (Marc Lou · Marc Lou (Apr 2026) ▶ 07:31)
• Rebuild duration: 4 months (self-reported) (unnamed guest · Eyal & Yahli (Nov 2025) ▶ 04:12)
• Share of features relevant to all users: 99 % (self-reported, approx.) (Zac · Zac (Jun 2026) ▶ 06:25)

Caveats & warnings

• Social features can come later, but requiring others for initial value complicates the app and means marketing to two people at once. (Lotts Ezeike · Lotts Ezeike (Nov 2025) ▶ 08:34)
• Generated features still need executing well (e.g. a check-in system ‘designed by child psychologists’). (Steph France · Steph France (Jun 2025) ▶ 19:40)
• His list-pruning approach may not be the most optimal way of working, but it has worked for him. (Rob Hallam · Rob Hallam (Aug 2026) ▶ 05:45)
• Without a time limit you’ll keep improving the product instead of shipping. (Mau Baron · Mau Baron (Jan 2026) ▶ 12:06)
• Customers sometimes don’t care how much work went into something. (Tom Holliday · Tom Holliday (Sep 2026) ▶ 10:50)

How much to trust this

• Evidence: 52 episodes, 51 independent speakers (repeat guests counted once; Pat and Gus counted as one voice).