Step 6 — Build / Pivot / Archive

You ran the experiment. Now you read what that small, cheap test of the solution told you and decide what happens next, before you've committed to building the real thing. That's this step. Three doors: Build the solution, Pivot to a different one, or Archive the work and walk away.

Most teams only know how to open one of those doors. They build. The experiment comes back lukewarm, the data says slow down, and they build anyway, because a team has been staffed and a thing was promised and stopping feels like failure.

It isn't. Stopping is the win.

The three paths

Each opportunity rides on a card (one card per opportunity, carrying everything you've learned about it so far: the problem, the experiment, the result), and that card lives on the opportunity backlog (the list of problems you're still testing, as opposed to the product backlog, which is the validated work you hand to engineering to actually build). Which door you pick is really a decision about what happens to the card next.

Build. You have real confidence the solution solves the customer's problem, so the card leaves the opportunity backlog and lands on the product backlog for engineering. Engineering has usually been in the room the whole way, so they already understand the problem and the solution before the handoff. This is the door everyone wants, and it's the rarest of the three, because earning real confidence is hard.

Pivot. You couldn't gather enough confidence in this solution, but the problem is still real and still worth solving. So you change the solution and try again. The key: a pivot stays on the same card. Same customer problem, new attempt at the solution. You're not starting over. You're using what the experiment taught you to take a better swing at the same thing.

Archive. The work doesn't clear the four gates from the assessment step: desirability (do customers want it), feasibility (can we build it), viability (does the business want it), and the ethicality gate I add (should we build it). Miss on any one and it doesn't fit the business or the customer right now, so you stop. And you write down why on the card before you close it. Future-you, or some other team eighteen months from now, picks up that card, reads why it got shelved, and skips re-running the experiment you already paid for.

There's a fourth move: persevere

The card model hides a fourth move: you can persevere. Keep the exact same solution and run it longer, on the bet that it just hasn't had enough time to break through yet.

Why does the card model hide it? Look at what each door does to the card. A build moves it to the product backlog. An archive closes it with a written why. A pivot writes a new solution attempt on it. Persevere changes nothing on the card at all, so the model has no state for it, and the move disappears.

People blur persevere and pivot constantly. Both keep the same problem and stay on the same card. The difference is the solution. Persevere is keep the exact same solution and run it longer. Pivot is change the solution and try a different swing at the same problem. Persevere changes nothing but the clock. Pivot changes the thing itself.

So persevere is for when the experiment didn't kill the idea and it didn't green-light it either. You believe there's a way through, so you give it more time to find out. You're not committing engineering, and you're not changing the solution.

Use it carefully. Persevere is the most dangerous move of the four, because it's the easiest to abuse. "Let's keep going" is what every team that should have stopped tells itself. The honest version has a deadline and a number attached. The dishonest version is archiving by another name, dragged out over six months and a lot of payroll.

How to tell which door you're at

Read the story your metrics are telling you.

That's it. Not your gut, not the sunk cost, not the exec who wants this to work. The number.

Each door has a different signature in the data. Build looks like the experiment clearing the bar: the metric you set out to move actually moved, customers reached for the thing on their own, the result holds up when you look twice.

Pivot looks like life in part of it but not the whole: most of what you tried fell flat, but one slice pulled real interest, so the problem is clearly worth solving even though this exact solution missed.

Archive looks like nothing: you're spending a lot and getting little back, few users, no real movement on the thing you set out to move.

Persevere looks like lukewarm but alive: the metric moved, just not enough to commit and not flat enough to kill, and you have a concrete reason to believe more time changes that. If that's your read, set the deadline and the number before you keep going.

When the data says stop, actually stop.

The hard part isn't reading the number. It's obeying it. At one company, I did a tremendous amount of research, we built a solution, and the people it was for shrugged at almost all of it. We built six or seven things into it. People really only liked one of them. When that happens you have a choice. Kill the whole thing, or look at what you built, find the one piece that actually landed, and pivot to that. So you take that one piece, make a couple of derivations of it, and see if anyone latches onto those instead. That's a pivot that came straight out of reading the data honestly instead of defending the original idea.

Real archives

One company I was at built an API (a way for other companies to plug their own software into ours) and handed it to our customers, betting that other customers would build on it too. They didn't. Hardly anyone used it. So we ran it back through a version of this exact process, a pseudo opportunity-backlog review, and the answer the data gave was the one nobody wanted to hear. We shut it down.

I used to argue this exact point with someone who was dead set on building an API for their team's work. My line was simple: cool, but if no one uses the API, who cares? You can stand up the most elegant thing in the world. If nobody's using it, congratulations on your useless piece of junk.

Here's another. A company I worked with had bought a small outfit whose product put flow meters on taps at bars, so you could pull real data on how much people were drinking and when. Good tech. Senior leadership wanted it to happen, because from a business perspective the pour data was a goldmine. As a brewer we didn't have access to that data at all. Because of how the company sales cycles went, restaurants may buy months of beer in one purchase because of a good sale the distributor was running. Which leaves the brewer with zero data that helps understand the consumer consumption.

But, for the frontline people who'd actually use it, the bar owners, it was worthless. I know how much beer I go through. I only have five beers on tap. I'm never going to run out of it. We spent a long stretch just trying to get any bar to use it, and no one was interested.

No experiment ever ran. No customer interviews either. That's the failure. An experiment, or even a handful of conversations with bar owners, would have surfaced that lack of excitement in a few afternoon phone calls or bar visits. Instead the company found out the expensive way, with the acquisition already made and a long push going nowhere. We skipped the cheap learning and paid full price.

This is an example of work that should have been archived, but wasn't.

Stopping is the win

Stopping the solution isn't stopping you. You closed one answer. The problem, and you, keep moving. Failure is always an opportunity to succeed somewhere else. It just means this wasn't the right place. A dead end isn't the end of the road. It's information about which way to turn next.

That reframe is the entire reason this process is worth the effort. Killing a solution that tested badly isn't a failure, it's the system working exactly as designed. You learned the thing was wrong by running a cheap experiment instead of building it for two years and watching no one use it. The win was learning it early.

I told a company once that I'm a dream killer. You're going to bring me lots of cool ideas, I said, and I'm going to tell you no to almost every one. People were stunned. But that's how you win. When Steve Jobs came back to Apple, he cut about 70% of the product line and focused everything on four computers. As he put it: focusing is about saying no. Saying no to the good-looking idea is what frees you to pour everything into the right one. The opportunity backlog is how you do it.

So read the data, pick your door, and write down why. Once you've earned the confidence to build, the next question is how engineering actually turns a validated solution into shipped product. That's Part 08.