Ship Decisions: Use Value to Decide When to Experiment and When to Finalize

As a consultant, I create many kinds of information products: both writing and speaking. I use the ideas of experiments and finalization to decide what to ship and when. That allows me the most flexibility in my product development.

However, too many organizations don't differentiate between what they need to ship as experiments and when to finalize the product. They persist on working on products that don't offer enough value for anyone. Not the customer and definitely not the organization.

Worse, it's actually easier to experiment with software than it is with information products.

I'll use my product development as an example to explain how my experimentation and finalization work.

How I Experiment

I experiment both with writing and speaking. The image to the left, from Successful Independent Consulting, shows the interaction between my writing and speaking. I start with something small—a blog post or an idea for a talk. Then, I take that short form idea and develop that enough to run an experiment.

I produce something valuable, in the form of an MVP, a minimum viable product, in all senses of those words. That's because the value is in a coherent piece of writing or a talk that makes sense. I don't need all of my ideas in this writing or talk. I need enough to publish as an experiment and get some feedback.

The feedback is a two-way street between my potential clients/readers/audience and me. I offer value in the form of these ideas. With their questions and comments, these people offer me value in their feedback.

I use that feedback to build more MVPs. That feedback arises from my writing, speaking, and consulting. That way, I have sufficient experience to corroborate these ideas.

And if no one appears to be interested in this MVP? I stop because I have more options. I might need to rethink who will gain the value from this work.

However, until I have enough MVPs, I don't finalize anything substantial.

How I Finalize

Because I publish a lot of words and deliver a lot of talks—my MVPs—I have a pretty good idea of where people will find value. I can then choose what to finalize in the form of a much longer effort, such as a long workshop or a book.

When it's time to finalize, I take what I learned form my MVPs and create deliverables. But I don't use the time I spent on MVPs to inform my planning. That's because I can use the ideas in my MVPs to create that longer work, but I often can't use the MVP itself. Your product development is totally different from mine in that respect.

Since it's easier to change software products if you keep them clean and polished all along, you might be able to use what you know from your MVPs to do a little prediction for finishing. But it's so much easier to keep everything clean as you add another MVP, even as an experiment.

My information products tend to live longer in their “final” form than your ever-evolving software products. (I'm not going to change a complete book or workshop once I deem it done.) Yet, we can both use the same ideas of looking for the value and deciding when to experiment and when to finalize. We both use agility based on value:

• Small MVPs offer everyone early feedback, possibly as an experiment. We can ship it because it's as good as it needs to be for now.
• Finalization offers the customers the assurance this product is ready to use, a different form of value. The product is done, done, done.

Value helps us decide when to experiment and when to finalize.

Assess Value for Your Ship Decisions

My ship decisions, especially for my MVPs, are relatively easy. Your product might need something different from an MVP. See Consider Product Options with Minimum Outcomes to see all the various minimums my clients have used.

Too often, I see premature optimization on a path that does not add value to anyone. Not to the customers, and not to the organization. That lack of value means companies work for too long on products that make no difference to anyone. (See Large Features and Long Deadlines Mean You Have a Gantt Chart, Not a Roadmap.)

But the more often your team releases something that offers some value, the faster you learn what the product actually needs. You can then decide if you want to continue with that product. Once you know you do want to continue, keep creating MVPS, in the sense of minimum and viable and product. That's when your customers can use the product and offer you feedback.

You can use these ideas:

• Expose the value with an experiment.
• As you build more experiments, continue testing that value so everyone sees some benefit.
• Postpone finalization as long as possible if that finalization requires polishing as my information products do. And if you have a software product, decide how you can integrate that polishing into every MVP so you don't have to polish at the end.

You, as I, might discover new markets and new products.