We are done! Hey now, not so fast.

Team: “There is value in all the work we are doing.”

Me: “Is it released to your users?”

Team: “We can’t release it until everything is finished.”

Me: “Oh. When will everything be finished?”

Team: “It could be months or years. This product is complex. But we have completed 30 features so far!”

Me: “Is anyone benefiting from those ‘completed’ features?”

Team: “Well, no, not yet. But it is all very valuable work!”

Sound familiar?

I’ve coached hundreds of teams and their management in over sixty organizations. And I’ve had small variations of this conversation many times. The starting point for many is, unfortunately, mistaking activity for value.

“Do not confuse motion and progress. A rocking horse keeps
moving but does not make any progress.”
― Alfred A. Montapert

Claiming victory on value requires us to broaden our horizons.

Let’s start with defining the common narrow view on value we have today. Then, we will expand. And expand some more.

We will then be done, or will we?

This year, I’ve committed my focus to a concept called Lean Leverage, as described in my inaugural 2024 post. Each article I craft this year, including this one, will focus on an aspect of Lean Leverage. Enjoy and stay tuned for many ways to do more with less.

---

The many ways we claim victory far too early.

Tasks are a means to an end, not the end itself.

Sure, it feels good to finish a task. But in most cases, many tasks are necessary to get a feature ready to ship. The required tasks need a diverse set of team members to come together and produce a working feature.

Just because you finish your part, you can’t claim victory; that would be selfish.

Yet, even with the best of intentions, this is precisely what happens on many teams.

Here are some examples of premature victories:

1. Needs understood: We understand what the user needs. We are done!
2. Experimental solutions tested: We identified possible solutions and which ones resonate best with the user. We are done!
3. User experience designed: We designed the interface. We are done!
4. Technical architecture designed: We crafted our technical design. We are done!
5. Front-end built: We are finished with the interface layer. We are done!
6. Integration layer built: Our component layer is complete. We are done!
7. Data model built: Our data layer is finished. We are done!
8. Integration tested: We completed QA and fixed all defects. We are done!
9. Acceptance tested: We finished our acceptance testing and resolved the problems. We are done!
10. Performance tested: The system has been tuned for performance. We are done!
11. Accessibility tested: All 508 compliance guidelines are met. We are done!
12. Security and compliance tested: The product is secure and meets all compliance rules. We are done!

No feature is shippable when any one of these tasks is finished in isolation; it’s all or nothing.

Claiming victory after any step is premature. Yet, many do this very thing. Task completion becomes the finish line when team members or teams specialize narrowly.

So, if a feature makes it through all steps, and it is shippable, are you done?

Not so fast. You complete a critical, working-product feedback loop by making a feature potentially shippable. But stopping here still confuses motion for progress.

Remember, rocking horses move a lot but go nowhere.

Any shippable feature that sits on a shelf provides value to no user and no organization.

Let’s expand our view.

---

Usable: “We deployed to users. Are we done yet?”

By making our product usable in the wild, we have taken a step in the right direction.

But product teams around the world over-produce features that will never be used. By some counts (The Standish Group Chaos Report comes to mind), 65-80% of features are rarely to never used. For some unfortunate products, even this number is conservatively low.

But many a team deploys and forgets.

They use the Field of Dreams approach to products: “Build it, and they will come.”

And the users never arrive. Even worse, the team often does not know because it has moved on to the next feature set. So, while deploying is better than putting shippable features on the shelf, it’s not enough.

The horse is still rocking.

We are not done, yet; let’s expand our lens again.

Used: “Our users are using what we built. Are we done yet?”

Adoption is exciting.

Now we are cooking, right?

Not so fast. What if users start using your feature and stop after a few times? What if they try it and then start spreading the word of a bad experience?

This no longer looks like a victory.

If product teams were perfect on the first try, things would be much simpler. But this is not reality. To get to the right product, we must try and, usually, try again.

Rocking, rocking, rocking.

Claiming victory on initial usage numbers is premature; let’s expand further.

Useful: “Our users are delighted by our feature. We are done.”

Iteration is crucial to emerge a product your users love.

To get all the way from concept to cash, you must delight users with what you build. Their workflow must be forever altered and simplified by your feature. You want repeat users, telling others about how your feature rocks their world (for the better).

Claim victory when users rage about features and your organization reaps the benefit.

Many of us stop short before we cross this finish line.

We do this because we:

• are too narrowly specialized.
• are anxious to start the next feature.
• are too confident we know the answer on the first try.

We fall victim to the “Rocking Horse Syndrome.”

Instead, we must keep laser-focused to achieve desired user outcomes and business impact.

And if you do this, congratulations. Now, you are done.

---

That’s it. I hope this helps you be unstoppable in your pursuit of value.

And I’m done with this post. Well, I am for now. Let’s see what you think, and I’ll go from there.

Related Reads

To go deeper, here are a few more reads related to this post:

Remove Date-driven Behavior to Achieve Agility—Focus on “Done”

How an output focus makes teams fail at Scrum

We Need One Complete Product Team