Where is the "Customer Development" aspect of the Lean Startup for Change approach?

In my mind so far, as well as in how I understand the work of Jeff Anderson and his team on this subject, the MVC is aimed at learning what approach works best in your context and doing experiments to adapt the approach.

This is similar to using MVP to find Product Market Fit with your core Product capabilities as the base you pivot around. For MVC the core capability you pivot around seems to be the Hypothesis that the direction/vision you have for the organization is indeed a good fit for what the organization needs.

As I understand it, Customer Development in the Product context is about finding a customer segment for which your MVP is a good fit. In the Change context Customer Development can be about finding the customer segment for which your MVC is a good fit, but this is more similar to classic Lean Startup. When we are talking MVC we are talking about searching for the right kinds of change WITHIN a change initiative you are already running.

So what is the Customer Development process? Is it searching for groups within the organization for which the MVC is good enough so they can use it to change and you can learn about the change approach together with them? Is it something that tries to verify that indeed the organization WILL benefit from this change program, rather than taking it for granted?

There is lots of value in seeking the right change approach using tactical MVCs. I think there might be at least as much value if not more in seeking fast learning on whether the change is the right one using strategic MVCs.

Come to think of it, in one of my current clients we’re using two strategic MVCs:

• Hunch1:  Small Batches are a good idea to deal with planning waste and effectiveness as well as bang for the buck product value for investment. We are testing that hunch using an experiment involving work on Product Backlogs / MMFs / Stories in 2 product streams.
• Hunch2: Cross-Functional work is a good idea to deal with synchronization overheads and waste involving half-developed features sitting on the shelf. We are testing that hunch using an experiment involving what we call “Discovery Kanban”. This is minimum because it is not a real Feature Team. But it provides enough learning to validate the value of Cross-Functional work. It doesn’t validate any hunches about Self-Organized teams though…

(Note we are not yet using Lean Startup disciplined Change Measure Learn loops, at least not explicitly. I look forward to doing something similar to what Jeff and his team are talking about…)

Any feedback welcome, and if you want to discuss in person, find me in Atlanta or Boston during the conferences, or check out a Kanban/Scrumban training we are opening in Atlanta just after the Scrum Gathering.

View the presentation

Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. Explore Business Agility advisory or let’s talk.