Podcast
Fast Time To Market
Hosted by lateralworks · ENGLISH
In the early 1990s, lateralworks conducted an extensive multi-company study involving over 500 people who worked on fast-to-market projects in Silicon Valley. Since then, they have worked with hundreds of teams to accelerate the delivery of new technology products to market. The research continues today to keep the best practices current.
This podcast series will share many of the practices that teams use to deliver the right product to the market at the right time.
16episodes
Episodes
Newest firstAll episodes
Creating an innovation culture
May 400:37:10Tap to summarizeThis podcast investigates the innovation paradox, which involves balancing the free generation of creative concepts with the necessity of rigorous evaluation. Successful companies like Google, Amazon, and Pixar thrive by prioritizing psychological safety, ensuring that early-stage ideas receive support before they face intense scrutiny. This specific sequencing of encouragement and critique prevents promising projects from being discarded prematurely and encourages employees to continue sharing their thoughts. Leaders are encouraged to view innovation as a sustained cultural habit rather than a rare event, utilizing structured rituals and management protection to foster growth. Ultimately, establishing an environment where risk-taking is rewarded and feedback is constructive serves to both drive business results and improve employee retention.
Transcribe →Triads for faster product development execution
Apr 2800:23:06Tap to summarizeThe discussion on the FTTM podcast delves into the Triad Model for faster product execution, based on lateralworks research. The model addresses the "ownership gap" and functional silos in traditional corporate structures by introducing a flat, three-person product ownership team: the End-to-End Owner, Process Owner, and Design Owner. These roles work in real-time collaboration to ensure seamless product development. The Technical Program Manager (TPM) drives execution using practices like "schedule as driver," "macro-micro planning," and "assume acceleration." The Product Delivery Team (PDT) model scales this approach across multiple product lines, emphasizing trust and speed over control. The Freedom Scale measures empowerment levels, aiming for level one (act, routine, reporting only) for most decisions.
Transcribe →Informed Ambition versus Blind Ambition
Apr 1300:24:18Tap to summarizeThe fundamental challenge in development organizations is the gap between aggressive leadership timelines ("targets") and reality-based execution forecasts ("plans"); when leaders treat ambitious targets as factual plans, honest reporting goes underground, schedules become fiction, and leadership loses visibility into real progress — much like a commander who punishes scouts for bad news and walks into an ambush. The solution is "informed ambition": let teams build their own plans to engage their ownership and drive genuine innovation, then transparently surface the gap between targets and forecasts as a shared strategic challenge to close collaboratively through descoping, parallelization, or added resources — because when people own their schedules they optimize them, but when schedules are imposed, teams become passive order-takers who abandon plans they know to be lies.
Transcribe →The Product Boss: FTTM Manager Role Profile and Competencies
Mar 1600:38:58Tap to summarizeDescribe the product boss and why this is so different from how companies organize product development projects. They lack the lateral end to end ownership rom concept to manufacturing or a single person who owns it. First observed at Sun Microsystems in their growth years in the 1990’s, lateralworks documented Sun’s use of dedicated core teams and product bosses which they said was the key to finishing on time with the right product. Product Bosses get freedom level 1. They are totally empowered, but they must have the skills of a true general manager, knowledge of every silo in the company and understanding of the customer and the market.
Transcribe →Planning and managing breakthrough innovation cycles
Mar 900:33:24Tap to summarizeThis is a discussion of a framework for managing and scheduling innovation by treating breakthroughs as a series of structured learning cycles. Rather than viewing invention as an unpredictable event, the authors argue that speed is achieved by failing fast to accelerate knowledge gain and compressing the time required for each experiment. Success depends on steering committees providing dedicated resources and shielding teams from corporate interruptions while avoiding group fixation on difficult problems. The strategy emphasizes challenging existing paradigms through lateral thinking and utilizing systems architects to manage complex technical interfaces. By using macro-to-micro planning, teams can maintain a rough long-term schedule while refining immediate tasks as new information emerges. Ultimately, the sources suggest that isolating high-risk innovations and running concurrent learning paths allows organizations to predict and meet market windows more reliably.
Transcribe →Shortening the long pole
Mar 200:31:11Tap to summarizeThe podcast "Shortening the Long Pole" is a discussion of a framework, a strategic method designed to accelerate project completion by targeting the most time-consuming constraints. This three-phase process begins with identifying the "ugly baby," which refers to being honest about the actual distance between current progress and the desired goal. The second phase involves critically analyzing root causes and challenging existing assumptions to eliminate unnecessary delays without compromising the project's core functionality. To maintain momentum, the framework emphasizes continuous optimization through frequent planning updates that iteratively reduce the timeline. Additionally, this podcast highlights the impact of innovation on schedules, noting that original inventions can extend project durations by several years compared to standard tasks. Real-world data serves to demonstrate how these principles effectively bridge the gap between projections and targets.Execution dragging? This episode is a rapid, practical guide to finding the one thing that’s secretly setting your pace, the “long pole” and cutting it down fast without breaking what matters. You’ll hear how to spot the real bottleneck (not the loudest problem), pressure-test the assumptions inflating your timeline, and use a simple “ask why until it hurts” approach to get to root causes instead of symptoms. The big payoff: a weekly cadence that keeps teams from thrashing, reduces cycle time in meaningful chunks, and turns vague “we need to move faster” into a clear plan that actually ships. If you’re tired of busywork, dependency gridlock, or plans that slip for mysterious reasons, this one will give you a sharper lens, and a playbook you can use immediately.
Transcribe →Scheduling Invention using Learning Cycles
Feb 2300:12:56Tap to summarizeIn this episode of the FTTM podcast, the hosts tackle the anxiety-inducing challenge of “Scheduling Invention,” how to build a real timeline when you’re trying to create something that’s never existed before, and argue that the only way to go fast is to plan to fail in a disciplined way, because accelerating controlled failure accelerates learning. They contrast “slow teams” that chase a perfect Big Bang plan (and end up delivering a perfectly solved problem the market no longer has) with “fast teams” that run repeated do it / try it / fix it learning cycles, replacing product milestones with learning milestones (e.g., “answer why component X fails” instead of “prototype complete”). The episode lays out practical tools like Learning Cycle Planning (estimating effort by number of cycles based on problem difficulty), isolating the true invention “magic” from execution (the “90/10” idea), surfacing the uncomfortable but essential gap between what the math says and what the market wants, and refreshing the plan weekly using a “confidence trend” metric so projects don’t stay green until they’re suddenly on fire. The punchline: a schedule that admits you’re late today is actually a win, because it gives you time to make honest trade-offs—while the schedule that pretends you’re on time is the one that quietly kills the project.
Transcribe →Sprinting Without The Critical Path
Feb 1600:17:13Tap to summarizeSprinting Without the Critical PathEver hit every sprint goal and still miss the deadline? This episode explains why.Many teams think they're sprinting, but they're still trapped by hidden dependencies, approvals, and late integration work. It feels fast, but the results are slow. We cover what "moving fast" actually looks like when you're dealing with complex programs—and how to track progress without pretending you can predict everything upfront.Agile vs. FTTMBoth want speed, but they solve different problems.Agile is about learning as you go - small chunks, constant adaptation, delivering value piece by piece. It shines when requirements are fuzzy and you need to figure things out.FTTM (Fast Time To Market) is about hitting a date - mapping dependencies, finding bottlenecks, and attacking them. It shines when you're coordinating multiple teams, suppliers, or hardware.The simple version: Agile helps you build the right thing. FTTM helps you deliver it sooner. They work well together—Agile within teams, FTTM across the program.
Transcribe →The Freedom Scale: A Continuum of Team Empowerment
Feb 900:37:28Tap to summarizeIn “The Freedom Scale: A Continuum of Team Empowerment,” the conversation digs into a super-practical question: how do you build teams that can move fast and ship real outcomes without turning into chaos? Using the idea of “heavyweight teams” (teams empowered to own an outcome end-to-end) and a Freedom Scale (a clear way to define what decisions the team can make on its own vs. what needs alignment), the episode breaks down how to set decision rights, avoid death-by-handoff, and create the kind of autonomy that actually increases speed instead of risk. If you’ve ever watched a “cross-functional team” get stuck waiting on approvals, dependencies, or invisible rules, this one gives you language and tactics to redesign the system so teams can truly own delivery.This is a discussion of a migration strategy for evolving organizational structures into high-performance, cross-functional teams. The framework transitions from basic functional hierarchies toward autonomous units that integrate engineering, operations, and marketing to increase operational speed. Central to this model is the Freedom Scale, a continuum of empowerment that defines the level of managerial control—ranging from "wait until told" for trainees to "act with routine reporting" for self-directed experts. Core team roles are clearly defined, including a Program Director for executive leadership, a Systems Architect for technical vision, and a Steering Arm of senior executives to provide strategic resources. Ultimately, the sources emphasize that project ownership and dedicated membership are essential for achieving rapid, successful product development.
Transcribe →FTTM is not Project Management - A debate (Part C)
Feb 300:19:24Tap to summarizeIn Part C of Episode 5 of the “FTTM is not Project Management” debate, the conversation gets practical: the hosts dig into where the line actually is between “FTTM” work and traditional Project Management work, why people keep mashing the roles together, and what breaks when you do. Expect pointed pushback, real-world examples, and a few “okay, but then who owns that?” moments, ending with takeaways you can use to clarify responsibilities, set better expectations, and stop the same arguments from looping forever. Here are the top 3 differences (FTTM = Fast Time To Market) versus traditional Project Management:The goal: “pull-in” vs “hold the plan” FTTM is explicitly about finishing sooner—a continuous effort to accelerate the schedule and hit the market window (“right product, right time”). Traditional PM is usually about delivering to the baseline (scope/schedule/cost), and a lot of the machinery is built around managing variance once it appears. How the schedule is used: driver vs reporting artifact In FTTM, the schedule is the driver of behavior: it’s built to show the gap between the target date and the “real” finish date early, and it’s used to create urgency and action. In traditional PM, the schedule often degrades into a status/reporting tool (updated for governance, not to actively change how the team works day-to-day). Cadence + ownership: daily team refresh vs PM-centric coordination FTTM emphasizes full team involvement, daily refresh planning (update → break down → pull-in), and trend tracking so the team can react before the slip (not after). It also pushes cross-silo integration (“lateralized” workflows tied to customer deliverables) rather than functional handoffs. Traditional PM more commonly runs on periodic updates, hierarchical decision-making, and coordination across silos.
Transcribe →