Fail Fast, Ship Slow: Lessons from Waze for Complex Delivery

There is a particular kind of silence that falls over a stakeholder meeting when a project is delayed and its not clear when or how it will be fixed, and everyone in the room knows it. I found myself in that dilemma a few years ago, just as I was ready to launch mobile ordering feature on the German app. EU regulation required something our app had never been built to do: show a customer the true cost of a drink, modifiers and all, before it landed in the basket. Simple to state, brutal to build. The German legal team weren’t budging and the app hadn’t been architected to look up store-level pricing on the fly, and every attempt to do it properly could slow the customer journey to a crawl. We were, by any conventional measure, behind. The room wanted a fix. What we came up with was a compromise — a reworked journey that met the letter of the regulation without the ideal performance. I remember thinking, somewhere around the third failed approach, that if I’d been asked to report when that feature would be released to the stakeholder group, it would have been “not yet” — and that “not yet” is a very hard thing to defend to people who fund things in quarters.

It’s a specific enough memory that I didn’t expect to be reminded of it through reading a startup memoir. But that’s exactly what happened reading Chapter 2 of “Fall in Love with the Problem, Not the Solution”, Uri Levine’s account of building Waze. It’s well worth reading not as a startup book at all, but as a manual for surviving the part of complex delivery that nobody puts in the business case.

“Fall in Love with the Problem, Not the Solution” brief summary

Levine’s chapter is a case study dressed as a confession. Waze began as a blank map, literally: no roads, no data, nothing but crowdsourced GPS traces from early users driving around Israel. If a hundred cars went one way down a street and none went the other, the system inferred a one-way. Two years of that kind of patient, unglamorous accumulation got Waze to something usable in a small, dense market with good fleet data behind it. Then came the global launch in 2009, and it was — Levine doesn’t soften this — a disaster. Ninety percent of new US users churned. The base maps were wrong. The routing was bad. The product that had worked beautifully in Israel fell apart the moment it met a country it didn’t understand.

What follows is the part of the chapter that has stayed with me. The team didn’t pivot. They didn’t rebuild from scratch. They spent the whole of 2010 doing something almost tediously disciplined: shipping a new version every two to three weeks, manually correcting maps street by street, and — this is the detail I keep coming back to — personally messaging users who’d been sent on a bad route, telling them they’d noticed, and asking them to try again. Trust, rebuilt one apology at a time, one release at a time.

Levine has a name for the terrain they were crossing: the desert of no traction. It’s the longest stretch of any project, the part where progress is invisible from the outside and deniable from the inside, and he offers two rules for surviving it that are almost insultingly simple to write down and viciously hard to live by. Don’t change direction. Don’t run out of fuel.

Failing Informatively: Why RAG Status Can’t See a Desert of No Traction

It would be easy to read this as a neat metaphor and leave it there — programmes have deserts too, how lovely. But I think the parallel is sharper and less comfortable than that, and it sits precisely in the tension between two things every senior PM has to hold at once: the discipline to keep iterating toward a solution you haven’t found yet, and the organisational pressure to report progress in a format that was designed for certainty.

Waze’s founders had one enormous advantage that most of us delivering inside large organisations don’t: nobody outside the company was watching the churn number in real time, and nobody had the authority to cancel the map. We don’t get that luxury. Our deserts of no traction happen inside steering committees, RAID logs, and quarterly business reviews, where “we are still failing productively” is not a status that shows up green. The German pricing rebuild wasn’t failing because we lacked competence or effort — it was failing in exactly the way Levine describes a hypothesis failing, which is to say, informatively. It meant that we had to delay the launch of the feature for several months until it could be re-engineered. Each broken approach told us something true about the constraint we were working against. But try explaining that to a room that wants a RAG status.

Rule 1 – Fail Fast

This is where I think Levine’s chapter offers something more useful to project managers than to founders, ironically. He talks about “fail fast” as a way of preserving run rate — capital and time, the two things a startup burns while it searches for product-market fit. In programme delivery, our run rate is a different currency: it’s stakeholder goodwill, it’s the credibility a PM has banked over years of delivering, and it’s the psychological safety of the team actually doing the failing. Spend that currency carelessly and you don’t just lose the current project — you lose the licence to be trusted with the next difficult one. The discipline, then, isn’t just failing fast. It’s failing in a way that’s legible to the people funding you, so that “not yet” reads as controlled iteration and not as drift.

Rule 2 – Don’t change direction

Levine’s other rule — don’t change direction — deserves a harder look too, because in my experience it’s the rule PMs break first under pressure, and usually with the best of intentions. When a stakeholder group is anxious, the instinct is to offer them a new plan, a different architecture, a fresh angle, because motion feels like reassurance. But a pivot born of anxiety rather than evidence is just a more expensive way of staying lost. What got our German rollout through wasn’t a new direction; it was the same direction, tested against reality repeatedly enough that the compromise we eventually landed on was actually informed by everything that hadn’t worked. The map only becomes accurate because a hundred cars drove the wrong way first and the system was built to learn from that, not to discard the road and try somewhere else.

Rule 3 – Retention: the metric that actually matters

Levine is unambiguous that product-market fit has one true measure: retention. Not downloads, not press coverage, not a good demo. Do people come back. I’d argue complex delivery has its own version of that discipline that we routinely dodge, because go-live is such a satisfying milestone to report against. But go-live is a vanity metric dressed as a finish line. The real test of our German rebuild wasn’t the release date — it was whether customers actually used the new journey, whether store teams could operate it under real footfall, whether the compromise held up outside the calm of UAT. A launch that technically ships but that nobody adopts, or that quietly breaks trust the way Waze’s global launch did, isn’t a delivery success. It’s a slower, more expensive failure wearing a status update.

The Cultural challenge in large organisations versus Startups

The part of Levine’s account that I think should unsettle project managers most, though, is cultural rather than technical. He describes the shift organisations need to make from asking “who is responsible?” to asking “what happened and what can we learn?” — and he’s right that the first question breeds fear and the second breeds experimentation. But he’s writing about founders who own their own culture. We’re usually operating inside cultures we didn’t design and can’t easily change, where the RAID log has a column for “root cause” that everyone quietly reads as “whose fault.” Perseverance through the desert of no traction, in a large organisation, isn’t just a personal discipline — it’s an act of translation. Part of the job is absorbing the “who’s responsible” pressure from above so the team underneath can keep asking “what did we learn,” because a team that’s afraid of the log doesn’t ship honest failure, it ships hidden risk.

The uncomfortable takeaway

I don’t think the lesson here is that perseverance is a virtue, full stop — that’s too easy, and it’s also not what Levine argues. Waze survived its desert because it kept the direction and kept the fuel, but it’s just as true that plenty of ventures die in that same desert doing exactly the same thing, for longer than they should. The book doesn’t resolve that tension and I’m not going to pretend I can either. What I’d offer instead is a narrower, more practitioner-shaped question, the one I actually had to answer in that stakeholder meeting: is what we’re learning from this failure specific enough, and fast enough, to justify the fuel it’s costing us? If the answer is yes — even a qualified, uncomfortable yes — then the job isn’t to change direction. It’s to keep driving the same road, correcting it street by street, and trusting that the map gets more accurate the longer you’re willing to be wrong in public.

That’s what we did in Germany. The feature we shipped wasn’t the solution I’d have chosen on day one. It was the solution that survived contact with everything that didn’t work first — which, I’m increasingly convinced, is the only kind of solution that ever does.