[Leadership laws] The innovation law of now or never

Quick description

You can’t push off starting work on the future until some later future. Or the future will always stay the future.

Your present will always be dominated by new urgent priorities that push the future out further, until I dies a slow death from lack of oxygen and light of day, to be replaced by some new future that you also won’t reach.

So if you map your work into stages or “horizons,” be sure to start on the essence of "Horizon 3" (or whatever you call your farthest out stage in your lingo) right now.

You already know this as it relates to products and services. This visualization in particular seems to be a favorite for making the point. People often use it to explain the lionized idea of the "minimum viable product" (MVP) visually:

And it certainly applies: However you describe your future vision, start on it now. Find something little and practical that relates to this value prop not something different that pushes your actual vision to some tomorrow that never comes.

But many professional intrapreneurs only apply this idea to the products and/ or services the create, not to the business side of their new offering. When it comes to proving value to the business of which they are a part, they implore executives to wait for a long time until there will be any kind of value.

To support their point, they may even insist that this is unavoidable and point to the "hockey stick growth curve" in support: "See," they may suggest to stakeholders: "Growth always starts very slowly and only compounds later. It's unrealistic to expect big value early." (Full disclosure: I have made this argument on several occasions myself.)

But here's the problem:

If you are an intrapreneur, working inside an existing organization, then your work must also be Credible to bosses and other stakeholders, on terms that matter to them. And cool solutions are simply not enough on that front. If you can't find some way to create an MVP that helps your stakeholders on business or operational fronts, you are essentially saying that you are creating useless output—not useless to you, and hopefully not useless to users. But useless to the org that pays your salary.

Sidebar rant for ultra-nerds: That drawing above doesn't actually describe MVPs

Ok, this is truly nerdy. But I found it an interesting nugget of new news. Sharing it in case the same is true for you. If not, just skip this little section. You won't need it for the rest of the post.

You've been warned. Read on at your own risk:

Henrik Kniberg, the author of the drawing above points out on his blog that people have taken his drawing to represent way more (and on way different topics) than he actually intended.

(BTW: You should really read Kniberg's post. really good.)

As for his original intent for the drawing, he writes:

"I drew this picture and started using it in various presentations about agile and lean development."

But people have used the drawing in other wise, some of which he appears to accept ... though others not so much:

"Since then the drawing has gone viral! Shows up all over the place, in articles and presentations, even in a book (Jeff Patton’s “User Story Mapping”  – an excellent read by the way). Many tell me the drawing really captures the essence of iterative & incremental development, lean startup, MVP (minimum viable product), and what not. However, some misinterpret it, which is quite natural when you take a picture out of it’s original context. Some criticize it for oversimplifying things, which is true. The picture is a metaphor. It is [also] not about actual car development...."

Kniberg goes on to describe his actual intent really simply and clearly, step by step and with good examples.

But even better is what he does next, namely to point out problems with the concept of MVP as it's actually used out in the world:

The underlying idea is great, but the term itself causes a lot of confusion and angst. I’ve met many customers that are like “No Way do I want an MVP delivery –  that’s the last delivery I’ll get!” All too often teams deliver the so-called Minimum Viable Product, and then quickly get whisked away to the next project, leaving the customer with a buggy, unfinished product. For some customers, MVP = MRC (Minimum Releasable Crap).

Instead, he advocates using one of a set of more practical descriptions: "Earliest testable, usable, or lovable" work, whichever one applies to your situation. Of course, the concept of "Minimum Lovable Product" has since taken on a life of its own. But the other two (testable and usable) are equally useful, IMHO.

Last point here: I agree with Kniberg that MVPs as actually used in the real world cause a lot of drama. After all, the "Law of Now or Never" exists because of one such problem.

But, just as a reminder: All of this hubbub about MVPs actually mis-uses Eric Ries' original definition and intent for the MVP. He meant for MVPs to be the "minimum testable thing," to use Kniberg's term:

"An MVP is the smallest version of a product you can use to start the process of learning from customers. Think of it as the first experiment or in-market test of our ideas. It needn’t be the full product; often it’s a version with elements removed or one made using a simpler production process. It can be as simple as marketing materials or a brochure."

And while Ries really does refer to the solution or something related to it in all direct quotes of his that I have seen, he also points out elsewhere that the real point is to test the riskiest assumption. If that riskiest assumption has to do with the business, operations, etc. rather than the solution itself, then the "minimum testable" thing might have no connection to the solution at all!

Phew, end rant. Back to our law and how to use it in real life. Thanks for bearing with me!

Litmus test

Definitely create "classic" MVPs focused on your solution. Just check that you also have MVPs for organizational Acceptability/ Agreeability:

Stage 1: Solution MVP: Can you point to a concrete way in which your current priority is a minimum version of your future vision, not to something else, pushing out what you want to work on into the future?

For example, when Netflix started, they did not open a video store while working on their "video over internet" vision. Instead, they created that version of "video over internet" that they could test out then, which happened to mean ordering video rentals over the internet but shipping them by mail.

Stage 2: Business/ operations MVP: Can your executive stakeholders, especially business line leaders, clearly repeat back to you how your output will add value to them? (Important: It matters that they can do it, not just that you can do it.)

Note that this must be possible without your leaders following their description with some serious caveat that negates all the value they have described before.

How to do it

General principles

Doing this can take multiple Viability and Acceptability/ Agreeability efforts. We can only cover the really short version here. But in short, especially consider:

• Make it tangible: Describe the financials that your effort will deliver, if you manage to de-risk the key assumptions: Opportunity size (TAM/ SAM/ SOM), resulting assumption-driven income statement (Discovery-Driven Growth), and payback period for investments.
• Make it helpful: It's hard to avoid the hockey stick growth curve. Stuff simply starts small. But financials aren't the only way to be valuable. Can you show how your solution will save operators time, cut headaches or risks, or otherwise earn its keep while you wait for financials to catch up?
• Re-mix it: It's possible that your as-is MVP can't produce any value to stakeholders on a timeline they care about. At that point, it may make sense to think of your single solution as a series of modules and to front-load those modules that matter most to your stakeholders.

Specifically method: The "Week 1 Solution"

Strategists use something they call the "Day 1 Answer." It's a way of laying out a complete hypothesis for solving a problem, including all sub-steps. Doing so ensures that you have understood the problem, have tied the high-level problem to specific actions, and made it possible to prioritize among those actions.

A "Day 1 Answer" is nice is all you need to offer is an answer or the ability for leaders to make a decision.

But innovation teams have to build, not just decide. And for building, the "Day 1 Answer" is not enough. You also need its cousin, the "Week 1 Solution."

The "Week 1 Solution" simply means that you take the first week of a project and go all the way from solution idea to a true, built solution. It's a bit like taking the Google Ventures Design Sprint one step further, by applying it not just to one part of the solution but to an entire solution.

Obviously, building an entire solution in a week is absurd. That's why you have the whole project. But make it possible by taking as many shortcuts, accepting as many simplifications, and going with as many assumptions as you need until it becomes possible.

The only thing that matters is reaching an endpoint that looks and acts like the final "thing" you will eventually hand off. That "thing" may be a physical product, but it could also be an analysis, or something completely different. It just has to be the real thing, not just a mockup.

The value of doing this is twofold:

First, realism: Things always sound easier in theory than in practice. Even if you draw pretty logic trees, storylines, and solution mockups, they will always miss complications from the real world, like missing data, lack of access rights, and many many more unwelcome surprises. By creating a Week 1 Solution, you flush out a bunch of those issues, so you are aware of them from the start and have more time to work through or around them.

And second, stakeholder comfort and usefulness: By showing that you can create output in a week, you take a huge burden off your stakeholders. They no longer have to trust that you can do it. They have already seen you do it. Unless they are total bozos, they will understand that your Week 1 Solution is vastly simplified and ugly. But they will still see that you proved that you can do it.
Beyond that, the stakeholders can become more useful to you: First off, you now can check whether you truly understood each other in your discussions about project outputs, in the sense of "show don't tell." If they don't like your output, it's best to know earlier rather than later, to have more time to come to a better agreement.
And finally, still on the topic of stakeholder usefulness to you: The best executives with whom I have worked actually have the skills to use these kinds of Week 1 Solutions as an artifact for their own work. In other words, they can take it to their stakeholders and build excitement and alignment mere days after you started your work. That Agreeability/ Acceptability work can massively increase the chances of success for your eventual, final solution.

So, in short: A Week 1 Solution doesn't delay your "real work." It massively speeds it up.

T.I.S.C.