How to anchor continuous customer validation in your innovation process?

Validated Learning: let’s recap

Validated Learning is a phrase that owes much of its popularity to the book The Lean Startup, by Eric Ries. It refers to the process in which you translate an assumption or an idea into a hypothesis, which you then test with an experiment, usually on end users. You process your data, and you learn. Presented graphically it might look something like this:

Assumptions could be the ideas you have about which of your features your clients will value the most. In an experiment with a dummy landing page you can then test if those assumptions were correct.

That way, you can grow towards your product or service step by step, by knowing which direction you need to take. The other way around: almost all startups that failed can pinpoint at which point Validated Learning could have saved them. “But we really thought a hula hoop that could send texts would fulfil a need…”

Long before you make an MVP, you can already make use of Validated Learning to discover if building the MVP is even worth the trouble. And parallel to creating your MVP, you can also test all kinds of other matters. Your terms and conditions, for example or — a bit sexier — your visual identity. Or your marketing website. Or your pricing strategy. Or your service desk. Or, or… well, you get the point. But how do you go about this?

First: create clear tracks

Most new Corporate Startups have their hands full with a plethora of to-do lists. Often a backlog, with everything that still needs to be done, is missing. Everyone just works like stink , and as long as we all try really hard and help each other we will be done first. Good chance that you will end up being right, too. At first.

But after a while you decide you would rather like to be better informed about which things still need to be done, as it is becoming more important that nothing falls by the wayside. That’s the time to start setting up various tracks concerning the specific product or service that you are developing. For example: Product Development, Marketing, Legal, Compliance, Service Desk, Community Building et cetera. But how do you organise that?

Scrum brings a rhythm

One solution starts with Scrum. A visual reminder:

I would never go as far as to say that Scrum is the solution to everything, but I have seen that Scrum can be very helpful in the development of these tracks.

Scrum could be applied to the marketing track, for example. And to the legal track. And if you allow those tracks to run synchronously, then you will find that they will automatically fall into the same rhythm. Like a basso continuo in music, it creates predictability and something to hold on to while the startup is progressing. That could look something like this:

If all the tracks run synchronously, then in practice that means they can all demo their progress during the Sprint Demo. A nice added effect is that everyone understands what everyone else is doing. In my experience, that kind of knowledge tends to get snowed under with everything that’s going on.

Does that mean that each track gets its own product owner? Not necessarily. This was the case at the last corporate venture that I advised, but then that team was about twenty strong. In a smaller startup you can identify a number of tracks, and then allocate multiple tracks to each team member.

Bonustrack: Validated learning

You can see that all the tracks run in parallel. A special track which we will now add is the Validated Learning track. Let’s look at a simple example with only two tracks, a Validated Learning track and a development track:

You can see that the output of the development sprint, for example a Wizard prototype, can be used as input for the next Lean Cycle. That Lean Cycle could be used to test, for example, if the consumer understands and values the wizard. The output of the Lean Cycle, for example a suggestion for improvement of the Wizard, can serve as input for the next Sprint.

So the hypotheses could be about the product, or, as I said, they could also be about other tracks. For example the hypothesis: “The customer is willing to pay 2.99 per month for the product,” or: “The customer understands the terms and conditions.”

Those hypotheses can be fed into the Validated Learning track, and the results can then be supplied back. Schematically, that could look something like this:

Here’s where the Learning Owner pops in

In an analogy to the product owner in Scrum, there is a learning owner in the Validated Learning track. That’s the man or woman who is responsible for supplying learnings, based on the inputs of others. That person’s formal function could be UX researcher, but what’s in a name? In any case, proper testing is an art form. The process could be described as follows:

1. Product owners from the other tracks enter their hypotheses onto the Hypotheses Board (using Trello, or Jira, for example) as they go. It is important that the product owner retains mental ownership of the hypothesis, after all, he or she is the person who wants to learn something!
   
2. The learning owner tweaks, asks for clarification where needed and helps the product owner to clearly formulate the hypothesis. Writing good hypotheses is something that requires practice.
   
3. The learning owner compiles a set of hypotheses that will be tested together in the next cycle, and suggests possible experiments. For example interviews, Facebook test campaigns, surveys, observations, etcetera.
   
4. The learning owner communicates this sprint planning to the product owners, and together they check if the priorities are still correct: are these experiments the right ones for us at this time?
   
5. The learning owner conducts the experiments. She has a whole host of test methods, and chooses the ones most fitting for the situation.
   
6. The learning owner processes the results of the experiments and documents them on the Hypothesis Board.
   
7. The learning owner presents a summary of the learnings during the Sprint Demo, during which other tracks also demo their progress.
   

This cycle is repeated every two weeks. You could think that the demo is the only time when information is exchanged, but that would make things very slow; the reason I wrote it like that was to make the graph a bit clearer. In practice, input and output are exchanged as fast as possible. We’re in a hurry, after all!

Lean and Scrum in one: Scream framework

So in actual fact the above is a combination of the Lean Cycle and the Scrum Method, hence the name Scream. I call it a framework, because it is a frame which you can fill with your own tracks to your heart’s content. Perhaps legal is not important to you at all, because your current goal is setting up a service desk. It’s a flexible solution, which you can streamline to fit your own startup as you go. Inspect & adapt, one of the most important Agile principles, remember?

Even though the framework is relevant for everyone, and we prefer not to have too much management, it is sensible to explicitly appoint someone who has the lead so that the framework is as effective as possible. Find someone who loves processes and Agile.

So, how should you set to work?

• Take a morning and design your own framework together
  
• Make someone “owner” of the framework
  
• Pay attention to it during the retro, and adapt it if that will make it better

In Short:

Validated Learning ensures that your corporate venture will make the right decisions. It begins even before your MVP, and is about more than just your product. Scream is a practical and applicable framework that anchors Validated Learning into your Corporate Startup.

Of course, I know there are more frameworks about. But in my experience this particular approach is nice and practical and therefore relatively easy to implement. Something for you? I would love to hear about your experiences!

Gert Hans Berghuis is senior partner and innovation strategist at Fabrique.com, the global strategic design company based in the Netherlands.