Why Most Product Planning Is Bad and What to Do About It By Angelo Saraceno | Oct 2, 2025 --- TL;DR Railway tried OKRs but found them caused more bureaucracy than clarity. They developed Problem Driven Development, a 4-day quarterly process focused on identifying problems (not solutions), team prioritization, and public commitment. This approach helped Railway maintain shipping velocity while scaling to 1.7M+ users. --- Common Issues with Traditional Product Planning Work typically ends up on the board by: A large, bureaucratic ceremony using assorted metrics. Reacting to urgent blockers needed to close deals. Founder-driven impulse to build something. None of these create a planning process that engineers love or that efficiently aligns the organization. --- Railway's Early Planning Challenges Reached a point where both bureaucratic ceremonies and urgent scramble to unblock deals were happening simultaneously. Used tools like Linear and implemented a lighter version of SAFE (splitting work into sprints, initiatives, and epics). Wanted a company vision with the ability for employees to propose projects. New work displaced old work constantly. They eventually adopted OKRs but found them limited. --- The Problem with OKRs and Software OKRs work well for concrete, measurable goals (e.g., factory output, sales targets). They falter with "unlimited" or creative objectives like improving conversion rates. Engineers struggle to formulate clear OKRs or tie work effectively to them. OKRs are inflexible once set, making mid-course corrections difficult. Leads to performative planning focused on "valid OKRs" rather than actionable work. At Railway, discussions often got stuck debating OKRs for days without deciding what to build. --- Moving Toward Projects and Themes Leadership provided top-level guidance via a dashboard containing metrics from product, GTM, and engineering. This created quarterly "themes" driving focus. Feature requests turned into "Project Candidates" prioritized as P0 (must deliver), P1 (quarterly goals), or P2 (nice to have). Worked initially in small teams but not scalable as team grew to 200+ people. Led to lots of meetings, over-planning, and emotional attachment to solutions. --- Emergence of “Problem Driven Development” Railway flipped their approach by: Asking teams to articulate problems, not solutions. Continuous collection of problem statements starting the Friday before planning week. No detailed requirements or RFCs at proposal stage—those come after commitment. Examples of problems look like: > "Users can't debug failed deployments without SSHing into containers." The Four-Day Quarterly Process Day 1: Teams enter problems independently. Incomplete problems go to a 'Parking Lot' for further refinement. Day 2: Planning captain holds a closed session for each team to assign priority (P0, P1, P2). Flags contentious or dependent problems. Day 3: Achieve ~95% certainty on priorities; tie-break dependencies; check cross-team dependencies and evaluate team capacity (accounting for commitments, on-call rotations, leaves). Decide if hiring is necessary. Day 4: Public commitment session; DRI (Directly Responsible Individual) assigned per problem. Then teams write RFCs and create implementation tickets. --- Benefits of Problem Driven Development Avoids the chaos of too many noisy voices by having teams prioritize internally first. Surfaces cross-team dependencies early to prevent mid-quarter surprises. Capacity check ensures realistic planning. Removes friction caused by premature solution proposals. Encourages psychological safety to raise problems without defending pet solutions. Minimal process focused on actual shipping and outcomes, not performative planning. --- Key Takeaways: Steal This Process Catalog problems, not premature solutions. -