Every Release Should Finish the Story

In my last article , I suggested that before teams build something, they should write the story.

What problem are we trying to solve? What evidence tells us the problem is real? What do we believe will improve? Why do we think this particular solution will help? And how will we know if it worked?

That’s the beginning of the story.

Unfortunately, that’s where many organizations stop writing it.

The solution gets built. It gets tested. It goes to production. Someone marks the work complete, maybe celebrates the release, and the team moves on to whatever is next.

But there’s still one rather important question left unanswered.

Did it work?

That’s how we finish the story.

At CAIP, this distinction became increasingly important as the team shifted from delivering requirements toward owning outcomes. Getting something into production wasn’t the end of the work. It was the point when some of the most useful information finally became available.

Now real users could experience the solution.

Now we could see what they actually did instead of what we thought they would do. We could compare the results against the conditions we were trying to improve. We could learn whether our assumptions were right, partially right, or completely wrong.

That’s information you simply don’t have before release.

We can research. We can interview users. We can analyze data, prototype ideas, and test designs. We should do all of those things when they help reduce uncertainty.

But eventually, reality gets a vote.

And reality is remarkably good at exposing our assumptions.

Go Back to What You Said Would Happen

This is why I like the idea of a pre-development narrative so much.

Before doing the work, the team has to put its thinking on paper. Not just what it plans to build, but why it believes that work will improve something.

Suppose applicants are abandoning an online process at a particular step. Research suggests they don’t understand what’s being asked of them, and the team believes clearer instructions will reduce abandonment.

That’s the hypothesis.

The team makes the change and releases it.

Now go back to the narrative.

Did abandonment decrease? Did users move through that step more successfully? Did support calls change? Did something else happen that we didn’t anticipate?

Those answers complete the story.

Without them, all we really know is that we delivered what we said we would deliver.

“Done” Is an Engineering State, Not an Outcome

There is nothing wrong with a team calling software done.

Development needs a definition of completion. Code has to be tested, accepted, deployed, and operational. Teams need to know when work can move out of their delivery process.

The problem comes when done becomes synonymous with successful .

Those aren’t the same thing.

You can successfully deploy a feature that nobody uses. You can perfectly implement a workflow that makes processing slower. You can deliver every requirement and discover that the original problem hasn’t moved at all.

The delivery can be done while the outcome remains unresolved.

That’s why measuring delivery and measuring outcomes serve different purposes. Delivery measures can tell us about pace, flow, and predictability. Outcome measures tell us whether that delivery translated into meaningful improvement. We need both, but we shouldn’t confuse one for the other. That’s also the distinction I’ve made in my metrics work: delivery measures reveal how work moves; outcome measures tell us whether it mattered.

What If It Didn’t Work?

This is where things get uncomfortable.

What happens when the team goes back to the narrative and discovers the expected outcome didn’t happen?

Good. We learned something.

That doesn’t automatically mean the idea was bad or the team failed. Maybe one of our assumptions was wrong. Maybe users behaved differently than expected. Maybe the solution helped, but another constraint became more important. Maybe we moved the metric, just not enough.

Now we know something we didn’t know before.

The failure would be spending the time and money to put something in front of users and then never bothering to learn from what happened.

A Product-Led organization values learning velocity because each cycle gives it better information for deciding what to do next.

The point isn’t to prove that our original idea was right.

It’s to find out.

Close the Loop

Imagine if every significant piece of work had a simple before-and-after story.

Before: Here’s the problem. Here’s the evidence. Here’s what we believe. Here’s what we’re going to try. Here’s what we expect to improve.

After: Here’s what actually happened. Here’s what we learned. Here’s what we should do next.

That’s not more documentation for the sake of documentation.

That’s organizational learning.

Over time, those stories create something far more valuable than a record of what an organization delivered. They create a record of what it learned about its users, its mission, and which interventions actually produced results.

That’s how teams get better at deciding what matters.

So yes, before you build, write the story.

But don’t stop when you ship.

Go back and finish it.

How often does your team return after deployment to determine whether the expected outcome actually occurred?

Reply or comment—I read every one.

CAIP is a program we follow throughout my book,