Scrum gave us a cadence, not a compass

Hello I'm Prerna Dabi, a software engineer at Rimo. Like many developers, I spend most of my time thinking about implementation, but I've become increasingly interested in the product decisions that happen before any code is written. That's what led me to attend this workshop, following a recommendation from my manager.

The room was filled with about forty participants, and I was the youngest. Jeff's teaching style encouraged curiosity and participation, so I ended up asking a lot of questions throughout the sessions. This post covers the ideas that come before building solutions the mindset, assumptions, and problem framing. In the next post, I'll cover the practical frameworks and techniques we learned for putting those ideas into practice.

Most engineering teams I know are good at shipping. We plan, we estimate, we review, we deploy, and we close the sprint on time. But how much of that work actually changes anything for the person using it? Jeff answered that in the first session.

Somewhere on day one, Jeff put up a slide with Marty Cagan's face on it and a single line coming out of his mouth.

Typically about 50% to 80% of all software we ship fails to accomplish its objectives.
Marty Cagan · author of Inspired · led product and UX at eBay for over a decade

Sit with that number for a second. Not 50 to 80 percent of projects run late. Not 50 to 80 percent have bugs. Half to four fifths of the software that actually ships, on time, at quality, reviewed and merged and deployed, does not do the thing it was built to do.

We are all quite good at the shipping part. That is the uncomfortable bit.

The workshop was nominally a CSPO certification and turned out to be a fairly direct argument about why that number is so high. I attended it as part of Rimo's training programme, from Japan, four hours a day across four days.

Jeff Patton wrote User Story Mapping (O'Reilly), the book that gave the industry the story map, and he is the person who developed the technique in the first place. He is a Certified Scrum Trainer and has spent about two decades teaching product thinking to teams that already know perfectly well how to build software.

Which matters for how this reads. He is not teaching people how to ship. He is asking teams that already ship well to re-examine what they are shipping.

This post is the first half: the framing that has to be right before any process can help you. Part 2 is the practical loop, from a target outcome to something you would actually release.

Throughout, we worked a running class exercise on the Marvel Unlimited app in breakout groups. I have pulled in what my group actually said, because in almost every case we stumbled into the concept ourselves about ten minutes before Jeff gave it a name, and watching that happen is more convincing than the definition.

Where Scrum actually came from

Jeff started somewhere I did not expect: 1986, a Harvard Business Review article called The New New Product Development Game by Takeuchi and Nonaka. That is where the word Scrum comes from, and it was not about software at all. It was a study of how companies like Honda and Canon developed new products.

The rugby image is the whole point. In a scrum the team moves down the field together, passing the ball back and forth, rather than handing it off in sequence from one specialist to the next. The article named what made those teams work, and the list is not what most of us practise:

• Built-in instability. Requirements are expected to change. That is a feature of the process, not a failure of the analysis.

• Self-organising teams. The team decides how to do the work.

• Overlapping development phases. Design has not finished when build starts. They run at the same time and inform each other.

Software adopted the word and, mostly, dropped the third one. We kept the ceremonies and the cadence and quietly went back to phases. Design finishes, then engineering starts. Discovery is something a different team did last quarter.

Which is how you get a team that is genuinely excellent at delivering, and still lands in Cagan's 50 to 80 percent.

Output done is not outcome done

This was the distinction that reorganised everything else for me.

Output done means the thing is built. It works, it is tested, it passes review, it is merged and deployed. Our definition of done, in practice, at most places.

Outcome done means it was released, people found it, they used it, and their behaviour changed in the way we intended.

Impact is what the business gets as a consequence.

Here is the part that stings: velocity does not measure the thing. Jeff's summary of the whole workshop fits on one line, and he wrote it on a whiteboard in red. Build less. The less you build to get the outcome, the better you did.

WHAT I'D TAKE BACK
If we had to write down the intended outcome for the last five things we shipped, and the metric that would show it, could we? For how many of them do we actually know what happened after release?

Waiter or doctor

Jeff's frame for how a team relates to its stakeholders, and it is uncomfortably easy to place yourself on it.

A waiter takes the order. The customer knows what they want, the waiter writes it down accurately, and success is delivering exactly what was asked for. Nobody blames the waiter if the meal was a bad choice.

A doctor does not take the order. If you walk into a clinic and ask for a specific prescription, a good doctor asks what is actually wrong with you first. Sometimes you get what you asked for. Often you do not, and you are better off.

The failure case Jeff used was the Amazon Fire Phone: an executive's conviction, built faithfully, rejected by a market nobody had properly asked. The counter-case was Spotify's Discover Weekly, where leadership had doubts and trusted the team anyway.

He was careful about one thing. You do not get to be a doctor by declaring yourself one. It requires stakeholders trusting you, which requires instrumenting your product and showing outcomes, repeatedly, until the trust is earned. And it needs what he called a bedside manner. Challenging a stakeholder badly just gets you labelled difficult.

IN THE EXERCISE

Our order pad

Day one, ten minutes, brain-dump everything wrong with Marvel Unlimited. We filled the board fast: search does not work, you cannot follow a storyline across different character arcs, offline downloads fail, it loads painfully slowly on Android tablets, it wastes the screen on foldables, and it never quite feels like holding a comic.
All true. All useless. We had produced a beautifully organised order pad, and nothing on it told us which problem mattered, or to whom. That gap is exactly what the rest of the week was for.

What actually counts as a product

Then Jeff pulled the definition much wider than I expected. A product is anything you make or do for someone else. A thing, a service, or a combination. Which means HR is a product. Your internal tooling is a product. The API your own engineers consume is a product.

The important move is outside-in thinking: define the thing by what someone gets from it, not by what you built.

He layered organisations into an onion: end products (what the customer is buying), customer-enabling products (the app, the website), employee-enabling products (branch software, call centre dashboards) and product-team-enabling products (services, APIs, shared components).

And then the distinction that quietly does the most work: choosers versus users. Whoever decides to buy or adopt is not necessarily whoever uses it. In consumer products they are usually the same person. In B2B, in internal tools, in anything bought by a leadership team and used by everyone else, they are not, and their interests can genuinely conflict.

IN THE EXERCISE

Who is this even for

Day three we spent a long time arguing about who Marvel Unlimited is actually for. Kids? Teenagers? Adults who grew up on the comics?
Then someone on my team said this, describing themselves:

"I'd say I'm a customer because I love the story, I love the adventure and the story, but I'm no longer a user. I will be a forever customer for Marvel."
There it was. Emotionally invested, financially committed, does not open the app. Someone else pushed toward teenagers, on the logic that they become paying customers in their own right in a five-year landscape. A third person brought up the milkshake story Jeff had told earlier, about parents buying the shake for their kids, which landed us on: parents are a main user, and customer, or both.
We had not been arguing about who the user is. We had been arguing about two different roles and calling them one word. Once we split chooser from user, the argument dissolved in about thirty seconds.

WHAT I'D TAKE BACK
For our own features, who chooses and who uses? Where those differ, whose experience are we actually optimising, and did we decide that on purpose?

Mission, vision, strategy: the guardrails

Jeff was upfront that experts contradict each other on these words, and that our own executives might define them differently. His definitions are useful precisely because they are sharply separated.

Mission is why the organisation exists. It is always true and it never completes, and it is never about size or growth. IKEA on affordable functional home furnishings for the many. LEGO on inspiring the builders of tomorrow. Tesla on accelerating the transition to sustainable energy, which is why Tesla selling solar panels and charging networks is not a distraction.

Vision is a story about how people will get value from your product in a future that does not exist yet. It should be slightly science fiction, because it depends on technology and conditions not available today. Its job is to make people feel something and pull them one way. The most common failure is a growth target wearing a vision costume. "Fifty thousand students by 2030" is not a vision. It describes nothing about the future you are building.

Strategy is the stepwise, quarter-by-quarter plan toward that vision, and unlike vision it has to be possible now. Jeff leaned on Roger Martin's Playing to Win: every strategic bet answers where will you play and how will you win.

IN THE EXERCISE

Spotify's missing vision

We were sent off to find Spotify's mission, vision and strategy. We could not find a real vision statement at all. What Spotify has is a set of strategic pillars: an enormous library, mobile first, heavy investment in discovery.
The interesting part was the contradiction. Spotify's mission is about unlocking human creativity and letting artists live off their art. Meanwhile the offline experience is bad enough to undermine its own accessibility goals, and the move into AI-generated music sits awkwardly beside a mission about paying artists.
Reading a company's mission against its actual product decisions turns out to be a fast and slightly ruthless diagnostic. I would not want to run it on us without warning.

Sensing: the part with no ceremony

The workshop's word for continuously noticing problems is sensing, and Jeff's position was blunt. Talk to customers at least once a week. Not once a quarter in a research readout. Weekly.

The channels: user interviews, watching people actually work, product metrics, support tickets, what the sales team keeps hearing, social media and forums, competitor behaviour, and dogfooding.

Two things from this section stuck hard. The first was a board he drew about running a product interview, with a note at the bottom: be interested, not interesting. The instinct in an interview is to demonstrate that you understand the domain. That instinct is wrong. You are there to be curious.

The second came from Sherif Mansour at Atlassian, who joined for a Q&A:

I don't do customer interviews without having a developer in the room. The number of lightbulb moments, the empathy gained, it's phenomenal.
Sherif Mansour · Atlassian

For a team like ours that is probably the single most actionable sentence of the week, and it costs nothing but a calendar invite. It pairs with a Leah Buley quote Jeff put up: "Design isn't a product that designers produce, design is a process that designers facilitate." The same is true of understanding users. It is not an artefact someone hands you.

One warning he repeated: do not move raw complaints straight into the backlog. A complaint is a signal, not a requirement.

IN THE EXERCISE

Workarounds are evidence

While digging through Reddit for real complaints, we found people had built their own third-party tools to work around the app. Someone on my team pointed out what that meant: users had gone and built the thing themselves, so the demand was already proven. Nobody had to guess.
That is the highest-quality signal you can get. Nobody builds a workaround for a problem they do not have. If our users are pasting things into spreadsheets or keeping a parallel doc, that is not a quirk, it is a spec.

Teams of teams

The last piece of framing, and the one Jeff illustrated with pigs.

A single product team owns a small product end to end and can move fast. As the product grows it stops fitting in one team's head, so you split it into product area teams, each owning a slice. Spotify's squads are the famous version.

The risk when you split has a name: Frankenware. Software that is technically complete and feels like it was assembled by four groups who never spoke, because it was. Each area team optimised its own slice and nobody owned the seams.

What holds it together is a shared vision, strategy, architecture and UX across the areas. And Jeff drew a clean line between two kinds of leadership that often get collapsed into one: product leadership decides what and why, functional leadership develops the people and the craft. One person doing both, badly, is a common failure.

WHAT I'D TAKE BACK
We are small enough that this is not our problem yet, which is exactly when it is cheap to think about. Where are our seams already, and who owns them?

So what was Scrum for

Scrum gave us a cadence. A rhythm for delivering predictably, at quality, without heroics. That is genuinely valuable and I do not want to give it up.

What it does not give us is a compass. Nothing in the ceremonies tells you whether the thing in the sprint should exist. Sprint planning does not ask who chooses and who uses. Standup does not ask which business problem this ladders up to. Retro asks how we worked, not whether the last release changed anyone's behaviour.

That is the gap Cagan's 50 to 80 percent lives in. Not bad engineering. Good engineering pointed at unvalidated things.

The original 1986 paper had the answer in it, in the phase we dropped. Discovery and delivery were supposed to overlap, in one team, continuously.

Part 2: Minimise output, maximise outcome
How you get from a business problem to a target outcome, how to generate and kill ideas, why the 2x2 should plot value against risk and not effort, the three different things people mean when they say MVP, and what running discovery and delivery at once actually does to your standup. Including the question I asked in the chat on the last day, which is the one that matters most for a team our size.