Why Planning Kills More Startups Than Bad Code (Serial Startup Founder)
The Product Engineers PodcastShow Notes
What if the real runway isn't money but learning speed? Anders Fredriksson has spent 20 years building startups and watching teams fail the same way: big plans, slow feedback, zero learning. Named Sweden's most prominent internet entrepreneur in 2007, he's now writing the book on what he calls the Speed methodology — Optimising Startups For Speed Of Iteration. In this episode, we dig into why backlogs are dead weight, why pull requests are your biggest bottleneck, and why end-to-end ownership changes everything. Anders shares how his team went from deploying every two weeks to 30 deploys per day, why the one metric that matters replaces your entire planning process, and what happens when AI agents take over the coding while engineers build the machine that builds the machine. GUEST Anders Fredriksson - Serial Entrepreneur & Author of "Speed: Optimizing Startups for Speed of Iteration" Anders has 20+ years of startup experience, from being named Sweden's most prominent internet entrepreneur in 2007 to now building Staer.ai, where the team writes virtually no code by hand. He's spent his career figuring out why startups move too slow and what to do about it. Find Anders: LinkedIn: https://www.linkedin.com/in/andersfredriksson/ X: https://x.com/andefred TIMESTAMPS 00:00 Introduction and Guest Welcome 01:00 The Speed Hypothesis: Small Steps Beat Big Plans 05:00 Implementing Speed at Ansen 09:00 No Backlog, No Sprints — Daily Experiments Instead 11:00 From Two-Week Sprints to 30 Deploys Per Day 14:00 When Speed Doesn't Apply: Known vs Unknown Solutions 19:00 Runway Is Learning Speed, Not Money 25:00 Generalists Win in the Age of AI 30:30 What's Left for Engineers When AI Writes the Code 36:00 Agents Working Toward Outcomes, Not Just Outputs 39:00 The Biggest Pushback: Killing Pull Requests 47:00 Top Tools and Practices: Monorepo, TypeScript, CI/CD 54:00 From Crashed Startups to Writing the Book on Speed 59:00 One Thing You Can Do Tomorrow Morning KEY TAKEAWAYS 1. Optimize for learning speed, not runway — if you're not learning fast enough, money won't save you. The build-measure-learn loop is only as good as your cycle time. 2. Replace backlogs with a One Metric That Matters (OMTM) — a living, short-term metric that every person in the company can impact daily. Change it frequently as you learn. 3. End-to-end ownership means engineers own the full loop — from understanding the customer problem to shipping to production and measuring impact. No handoffs to product managers. 4. Pull requests are your biggest bottleneck — asynchronous code reviews kill deployment speed. Replace them with synchronous pair programming or, with senior teams, skip reviews entirely. 5. The engineer's new job is building the machine that builds the machine — maintaining agent infrastructure, removing friction, and ensuring AI can verify its own work. 6. Do the bottleneck workshop — map every step from feature idea to production, multiply frequency by time, and fix the biggest number first. RESOURCES MENTIONED - "Speed: Optimizing Startups for Speed of Iteration" by Anders Fredriksson (upcoming book) - Lean Startup by Eric Ries (build-measure-learn loop) - Nx (monorepo orchestration tool) - Blacksmith (fast CI runner) - Kubernetes (container orchestration) CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti Website: https://productengineers.com LinkedIn: https://www.linkedin.com/company/product-engineers SUPPORT THE SHOW If this episode made you rethink how fast your team actually moves, share it with a founder or engineer who's stuck in two-week sprint cycles. Drop a comment below with your biggest takeaway. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit podcast.productengineers.com
More from The Product Engineers Podcast
What happens to engineering when AI makes software easier to build? Marty Cagan, founder of Silicon Valley Product Group and coauthor of "EMPOWERED: Ordinary People, Extraordinary Products", argues that engineers' role in shaping the product becomes even more important. Their knowledge of technology helps them see new possibilities, challenge proposed solutions and decide what is worth building. We explore engineers' contribution to product innovation, what discovery looks like in an engineer's day, and why handing over an AI-generated prototype to be made production-ready can recreate the feature factory. Marty also distinguishes empowerment from autonomy, discusses how AI could help smaller teams own more of the product, and shares practical ways engineers can start changing how their teams work. In our conversation, we discuss: 1. Why engineers can be your strongest source of product innovation 2. Why using AI to speed up a feature factory can deliver failed products faster 3. How engineers can make time for discovery and help shape prototypes before a solution is decided 4. How empowerment differs from autonomy, and why smaller AI-assisted teams could reduce dependencies 5. How to start changing a feature factory from within through customer contact, usage data and small experiments Where to find Marty Cagan: • LinkedIn: https://www.linkedin.com/in/cagan/ • SVPG: https://www.svpg.com/team/marty-cagan/ Where to find Peppe: • LinkedIn: https://www.linkedin.com/in/peppesilletti/ • X: https://x.com/peppesilletti • Website: https://peppesilletti.io Where to find The Product Engineers Podcast: • Website: https://productengineers.com In this episode, we cover: (00:00) Introduction (00:56) Feature factories and empowered engineers (07:30) The product model and owning the problem (12:31) Four product risks and why engineers should push back (20:46) How AI changes product teams, discovery and delivery (26:25) The AI productivity paradox (31:53) Daily discovery and the prototype handoff trap (37:08) Developer tools and understanding your customers (42:58) Smaller teams, empowerment and autonomy (46:53) How engineers can start changing a feature factory Referenced: • EMPOWERED: Ordinary People, Extraordinary Products, by Marty Cagan and Chris Jones: https://www.svpg.com/books/empowered-ordinary-people-extraordinary-products/ • The AI Productivity Paradox, by Marty Cagan: https://www.svpg.com/the-ai-productivity-paradox/ • A Fresh Definition of the Product Role, by Marty Cagan: https://www.svpg.com/a-fresh-definition-of-the-product-role/ • Benedict Evans on Another Podcast: Most people and companies aren’t tool-builders: https://open.spotify.com/episode/4NkYXMBNyXqxihujGGSytc • Atlassian: The State of Teams 2026 (source of the 89%/6% figures): https://www.atlassian.com/blog/state-of-teams-2026 • Earlier episode with Meikel Ratz at PostHog: Why "Just Coding" Isn’t Enough Anymore: https://productengineers.com/episodes/season2/why-just-coding-isnt-enough-anymore/ • Product Therapy, hosted by Christian Idiodi (SVPG): https://podcasts.apple.com/us/podcast/product-therapy/id1738373011 • Claude Code: https://claude.com/product/claude-code • Cursor: https://cursor.com/ • OpenAI Codex: https://openai.com/codex/ • Lovable: https://lovable.dev/
How can engineers get involved in product work when they usually receive a roadmap, finished designs, and a ticket to implement? Teresa Torres, product discovery coach and author of Continuous Discovery Habits, explains how engineers can participate while the team is still learning about customer problems and deciding what to build. In our conversation, we discuss: 1. Why getting involved before sprint planning gives engineers more room to contribute 2. How to build relationships and ask for customer and business context 3. How to find people with the problem your product solves and collect specific stories 4. Why AI coding agents still need product, design, and engineering expertise 5. How to bring what you learn to the team and influence change through your own habits Episode transcript: https://productengineers.com/episodes/season2/how-engineers-can-get-involved-in-product-work-teresa-torres-continuous-discovery-habits-author/ Where to find Teresa Torres: • Product Talk: https://www.producttalk.org/ • LinkedIn: https://www.linkedin.com/in/teresatorres/ • X: https://x.com/ttorres Where to find Peppe: • LinkedIn: https://www.linkedin.com/in/peppesilletti/ • X: https://x.com/peppesilletti • Website: https://peppesilletti.io Where to find The Product Engineers Podcast: • Website: https://productengineers.com In this episode, we cover: (01:05) Why engineers need a say in what gets built (04:09) Getting involved before sprint planning (06:38) Building trust and asking for product context (14:38) AI coding agents and the product trio (24:39) Why tiny product teams may not stay tiny (27:32) Finding people with the problem your product solves (30:33) Learning from specific stories and spotting product gaps (39:14) Bringing what you learn back to the team (41:47) Changing your habits, humility, and where to find Teresa Referenced: • Continuous Discovery Habits: https://www.producttalk.org/continuous-discovery-habits/ • Product trios: https://www.producttalk.org/product-trios/ • Customer interviews: https://www.producttalk.org/customer-interviews/ • Product Talk Podcast: https://www.youtube.com/@ProductTalkVideos • All Things Product Podcast: https://www.youtube.com/@AllThingsProductPodcast
What does business sense for engineers look like in practice? Arnon Cavaeiro joins me to talk about product engineering, product discovery and choosing which customer problems to solve. We get into revenue, costs and product strategy, and how understanding them helps you decide what to build next. The conversation moves from discovery to delivery, with practical questions engineers can bring to their next project. Why can a feature go unused even when a customer requested it? What is the smallest experiment that would test your riskiest assumption? Arnon shares how to use early signals before revenue catches up, make the business case for technical debt, and navigate the growing overlap between engineering and product management. In our conversation, we discuss: 1. Why understanding revenue and costs changes what engineers choose to build 2. How to judge customer problems by reach, pain and relative priority 3. Why customer requests need small experiments and clear product positioning 4. How leading metrics help you change direction before revenue catches up 5. How to connect technical debt and engineering decisions to business outcomes Where to find Arnon Cavaeiro: • LinkedIn: https://www.linkedin.com/in/acavaeiro/ Where to find Peppe: • LinkedIn: https://www.linkedin.com/in/peppesilletti/ • X: https://x.com/peppesilletti • Website: https://peppesilletti.io Where to find The Product Engineers Podcast: • Website: https://productengineers.com In this episode, we cover: (00:00) Introduction (03:23) Why engineers need to understand the business (07:15) Choosing problems worth solving (09:56) Small experiments and risky assumptions (13:16) Unused features, customer requests and positioning (16:57) Building as thinking, prototypes and taste (26:05) Outcomes, experiments and leading metrics (35:33) Making the business case for technical debt (41:40) Who owns product decisions? (47:08) Closing thoughts and where to find Arnon Referenced: • Taste Labs: https://tastelabs.com/ • Linear: https://linear.app/
Robert C. Martin, also known as Uncle Bob, joins The Product Engineers Podcast to discuss why technical expertise still matters when AI writes the code. The author of Clean Code and Clean Architecture explains how those principles help engineers steer AI coding agents towards better software. We get into Robert's use of static analysis, complexity and coverage metrics, dependency checks and mutation testing. He shares how he stays technically involved while reading less code, and why understanding customers is essential to choosing the right technical constraints. In our conversation, we discuss: 1. Why clean code and clean architecture still matter when AI writes the code 2. How static analysis and dependency checks help steer agents towards better software 3. How Robert combines acceptance tests, QA tests and mutation testing to check AI-written code 4. How engineers can stay technically in control without reading every line of code 5. Why understanding customers leads to better technical decisions Episode transcript: https://productengineers.com/episodes/season2/why-hardcore-technical-focus-still-matters-big-time Where to find Robert C. Martin: • X: https://x.com/unclebobmartin • Website: https://cleancoder.com/ • Videos: https://cleancoders.com/ Where to find Peppe: • LinkedIn: https://www.linkedin.com/in/peppesilletti/ • X: https://x.com/peppesilletti • Website: https://peppesilletti.io Where to find The Product Engineers Podcast: • Website: https://productengineers.com In this episode, we cover: (00:00) Why technical expertise still matters with AI (05:27) Agile, customer contact and organisational change (08:39) Learning from customers without losing technical depth (13:19) Connecting technical requirements to customer needs (18:00) Clean code, static analysis and quality metrics for agents (23:48) Enforcing architecture and checking behaviour with tests (28:26) TDD, reading less code and staying technically in control (34:27) Where deep specialists matter and who can build with AI (40:30) Where to find Robert Referenced: • Clean Code: https://www.informit.com/store/clean-code-a-handbook-of-agile-software-craftsmanship-9780135398579 • Clean Architecture: https://www.informit.com/store/clean-architecture-a-craftsmans-guide-to-software-structure-9780134494166 • Agile Manifesto: https://agilemanifesto.org/ • CRAP4J: the complexity-and-coverage metric discussed in the episode • Gherkin: the acceptance-test language used in Robert's workflow
Everyone tells engineers to talk to users. But what should you ask, and how do you turn the answers into better product decisions? Sara Iacozza is a Senior UX Researcher and Product Strategist with 7+ years of experience helping teams understand user behaviour and decide what to build. In our conversation, we discuss: 1. How understanding users helps engineers make trade-offs and find simpler solutions 2. How to practise user interviews with colleagues, an AI coach, and a researcher’s feedback 3. How to avoid leading questions, use plain language, and ask about real experiences 4. How to turn interview notes into shared insights and check AI analysis against the evidence 5. How to get closer to users by shadowing interviews, watching recordings, and talking to colleagues Episode transcript: Where to find Sara Iacozza: • LinkedIn: https://it.linkedin.com/in/sara-iacozza/ Where to find Peppe: • LinkedIn: https://www.linkedin.com/in/peppesilletti/ • X: https://x.com/peppesilletti • Website: https://peppesilletti.io Where to find The Product Engineers Podcast: • Website: https://productengineers.com In this episode, we cover: (00:00) Introduction and what UX research involves (06:35) Why user research matters for engineers (12:33) Learning to interview users, with practice and AI (24:19) Avoiding leading questions and polite answers (28:39) Using language your users understand (33:08) Turning conversations into insights and checking AI analysis (42:00) Making research part of the team’s work (45:20) Getting closer to users when access is limited (51:35) Where to find Sara Referenced: • Sara’s User Interview Coach (announcement and access link): https://www.linkedin.com/posts/sara-iacozza_chatgpt-user-interview-coach-activity-7296141061372993536-pWZQ • Continuous Discovery Habits by Teresa Torres: https://www.producttalk.org/continuous-discovery-habits/