Papers
Research findings, methodology papers, and field-tested frameworks from the lateralworks team. New papers added regularly — check back.
Roles and responsibilities in the Product Delivery Team model
Core thesis. The Product Boss exists to take a product from concept to market as fast as possible. They are the enforcement arm of the operational product strategy and the embodiment of FTTM at the product level. Without one person owning each product end to end, the program can define policies but cannot ensure compliance.
How empowered core teams govern the frozen specification and protect the launch date
Core thesis. Time to market and change control are the same subject. Every change to a frozen specification carries a schedule cost and a financial cost, and an organization that cannot price those costs will accept every change and miss every date. The fastest organizations give one small board authority over the specification, arm it with a live schedule and a cost-of-delay model, and make that board the core team itself.
The non-negotiable weekly refresh, and why cadence is the one thing your team can always control
Core thesis. The weekly schedule refresh is your project's made bed — the one event whose existence depends only on the team's own discipline. Run on a fixed three-day rhythm, it produces a specific pull-in decision every week and turns the schedule from a record of the past into an instrument for changing the outcome.
Find the path that sets the end date, challenge the assumptions holding it up, and whittle it down every week
Core thesis. The long pole sets the end date. Most organizations watch it grow; fast teams cut it down. Find the real long pole, challenge the assumptions that hold up its duration, cut in big chunks without letting the tent fall down, and whittle it every week through refresh planning. Do this and the end date becomes something the team sets, not something it discovers.
Balancing the portfolio for speed
Core thesis. The active project portfolio is a zero-sum game. Best-practice companies balance it deliberately: manage the fuzzy front end on a clock, rank every candidate against weighted business objectives, and gate each start against real resource capacity. When one project is added, another is killed or deprioritized. Organizations that skip this discipline overload the engineers already carrying the committed portfolio and deliver everything late.
Roles, not functions: how heavyweight, lateralized teams become the single greatest contributor to development speed
Core thesis. A cross-functional core team is not a group of functions assigned to a project. The FTTM core team carries three critical roles at its center — a chief engineer, a product leader who is the voice of the customer, and a system architect — held together by a heavyweight technical program manager who acts as the integrator. Those roles pull the whole program sideways, across the functional walls, from first definition to final delivery. That lateral pull is what produces speed. Of everything a company can change to get to market faster, the team is the largest single lever.
How an honest schedule reveals whether you are building the right thing, in time to do something about it
Core thesis. Every program carries three truths — the market's target, the schedule the team can deliver, and the requirements that define the product — and most organizations collapse them into a single date. The schedule is the only one that produces a measurable signal every week, so an honest schedule is the first truth to break the silence and force the harder question: are we building the right thing at all?
How to build a culture where new ideas are both encouraged and stress-tested without being killed
Core thesis. Strong ideas arrive rough and need room to develop before judgment. The same rigor that makes a company good at execution can kill ideas in their fragile state — so the leader's job is to sequence the work: support first, scrutiny second, refinement throughout.
Truth-based planning versus top-down targets
Core thesis. The debate between aggressive and realistic scheduling is a false dichotomy; the real question is who owns the plan. When the people doing the work own the schedule they fight to deliver it, and when leadership imposes it the gap between target and reality goes underground — surfacing late, expensively, and without warning.
Priority-based budget optimization for resource-constrained programs — how AHP decision models protect mission-critical spending and eliminate waste.
Core thesis. Every dollar is an investment in the company's primary objective: spending that accelerates the mission is protected, and spending that does not is cut. A structured decision model makes the distinction explicit, defensible, and immune to the politics that turn most cost programs into across-the-board reductions.
How complexity outran integration — and why technology programs still slip, overrun, and break at the seams
Core thesis. Modern program failure is not a shortage of engineering talent or project-management software. It is the absence of two roles — the systems architect and the systems planner — that once owned the integrated whole; complexity grew while the integrators disappeared, and the slips and integration failures we treat as unavoidable are the predictable result.
Building organizations that anticipate problems — and hiring the C-suite that will
Core thesis. The happy schedule is the blue pill; the reality-based schedule is the red pill. Anticipation is not a personality trait — it is a behavior the organization either rewards or punishes, and that C-suite leaders either model or suppress.
Heavyweight teams, real empowerment, pulling pain forward, and the trouble with happy schedules
Core thesis. The four questions look like separate topics — team design, delegation, risk timing, and scheduling. They are one topic. Speed comes from a team that owns the outcome, an explicit envelope of authority that lets it act without asking, a culture that surfaces problems early, and a schedule the team believes and the organization can trust. Remove any one and the other three lose their force.
How fast teams question assumptions to close schedule gaps and break through technical problems
Core thesis. A late schedule is not only a tracking problem. It is a thinking problem. When a team treats its current plan as fixed, the only moves left are to admit defeat or to cut the product. Challenge opens a third move: question the assumptions behind the plan, then find a faster way to reach the same goal. Used deliberately, it turns a schedule gap into the pressure that produces a breakthrough.
Ten proven practices that consistently move products to market faster
Core thesis. Fast time to market is not the result of working harder. It comes from ten disciplined practices, installed together, that turn the schedule into a living instrument and the team into its owner. Speed is not an outcome — it is a habit, protected one Tuesday morning at a time.
Happy schedules, the gap, and the discipline of finding reality early
Core thesis. Three practices share a single discipline: bring reality forward in time so the team can act on it. Accelerate the pain so urgency arrives early. Build a schedule honest enough to expose the gap. Track the trend so you see slippage before it lands. Each practice fails on its own without a host environment that rewards early honesty.
Four failure patterns we keep seeing — and why traditional project management cannot solve them.
Core thesis. Advanced technology programs do not fail because the work is too hard. They fail because four organizational patterns — distributed sites, multiple companies, multiple corporate stakeholders, and simultaneous innovation with product development — overwhelm conventional project management. FTTM is the operating system built for these conditions.
How to predict and accelerate advanced technology development
Core thesis. Innovation is not random. The duration of a breakthrough can be approximated by counting learning cycles and multiplying by typical cycle time, sized against problem difficulty. Programs accelerate by working two levers in parallel: more cycles running concurrently and shorter cycle time per cycle.
Twenty years of compounding technology innovation outran the way technology programs are managed. The lateralworks case studies show what works instead.
Core thesis. Technology capability has grown by orders of magnitude since 2005. The way technology programs are managed has not. Agile sped up feedback loops inside software teams but did not fix the structural problems that make complex programs late. The lateralworks FTTM methodology, refined since 1988 across 200+ programs, is the documented exception. The case studies are the evidence.
How fast teams figure out what to build and when it has to ship, and why the answer keeps moving while they build it.
Core thesis. Right-product is determined first, not last. Voice of the customer is how fast teams figure out what 'right' means today, then again next month, and again until the program ships. Programs that freeze the requirements early ship the wrong product into the right window, or the right product into the wrong one.
How to govern what enters the active pipeline so the work that starts actually finishes
Core thesis. Most product organizations start more projects than they can finish. The cure is not better execution. It is a portfolio discipline that ranks every candidate against weighted strategic and economic criteria, then gates entry to the active pipeline against real resource capacity. Rank without constraints first. Apply constraints second. One person owns the call. Starting fewer projects is how more projects finish on time.
How dedicated resources accelerate new product development
Core thesis. One to two projects per engineer is the maximum sustainable load for complex new product development; past two, context switching consumes 40 to 75 percent of working time, queue delays compound at every milestone gate, and calendars slip by months — the structural fix is dedicated cross-functional product teams governed by an explicit portfolio and clear decision rights.
Where the biggest schedule opportunity hides — and how to capture it through dedicated teams, a refreshed schedule, and a hard cycle-time target
Core thesis. The fuzzy front end is the largest, cheapest, and least-managed source of schedule slip in technology product development. Treat it as a real project — with a dedicated cross-functional team, a weekly-refreshed schedule, and a hard cycle-time target — and months come out of the development calendar without compressing the engineering work that follows.
Aggregating live project schedules into a single leadership view
Core thesis. Most leadership teams running multiple programs cannot see their portfolio in time to act. fastProjectAI fixes this by aggregating live wigglechart data the PMs already maintain — surfacing the small number of projects that need attention this week, not the long tail that does not.
A framework for measuring and improving team performance
Core thesis. A team’s schedule maturity is observable, measurable, and migratable. Teams move through four levels — from ML0 (no schedule) to ML3 (active acceleration) — by changing specific behaviors in the weekly refresh. Knowing where a team sits on this curve is the prerequisite to changing it.
How executives create the conditions for fast product development
Core thesis. Teams deliver products; the host creates the conditions under which they deliver fast. Fix the host and speed becomes the default. Leave the host alone and team-level improvement fades within a year.
How fast teams get the right product to market at the right time
Core thesis. A fast team organizes itself around the customer (right-product), assembles the smallest competent group of role-owners (right-team), and uses its schedule as the primary tool for driving decisions and exposing gaps (right-time). Inside a provisioning host, these 15 practices cut time-to-market by 30 to 50 percent.
Why senior-manager failure modes kill the innovation their organizations depend on
Core thesis. Innovation needs encouragement before scrutiny, but most organizations evaluate too early and kill fragile ideas. Senior managers either over-invest in managing up (optimizing the upward narrative) or over-invest in managing down (deep in operational weeds). Both break the protection-from-above the innovation environment depends on.
Three decades of fast-team research, 2018 revision
Core thesis. FTTM outcomes are a function of two inputs — the behavior of the team and the environment within which the team operates. Best practices observed across hundreds of programs are codified into a Mindset / Host / Team framework that delivers the right product at the right time.
29 papers. More papers added regularly.