More Compare and Contrast of Cynefin and The Lean Startup

I got some heat over the weekend from Dave Snowden (@snowded). I did a bit of a mangling of Cynefin in my last post. I want to clarify my comparison of Cynefin’s complex domain to the Lean Startup concepts. I understand that Cynefin is a general framework about understanding business problems and processes, while Lean Startup is about creating software. So why am I saying they are related? 

I’ve said before that complexity is the underlying problem of product management. Cynefin has a useful set of thinking about what to do in a complex domain. The Lean Startup, which is specifically about product planning, has a similar set of points. These points reinforce each other. And they validate my fundamental claim that we need to think about product planning as a different kind of beast than other business processes, especially when it comes to tools.

Let me give an example. 

Financial accounting is a “simple” domain, from a Cynefin standpoint. There are best practices, there is a right answer at the end of the day. For nearly any question, there’s a specific answer. 

If I’m thinking of making a software product for the financial accounting, there are a number of different components I could focus on, such as the General Ledger, Accounts Receivable, Accounts Payable, reporting. 

For each of these components I could either implement that component in my software or not. I could implement it as a version of the traditional approach – i.e., a ledger or a spreadsheet – or in any of dozens of different non-traditional user interfaces. I could put charting in my reporting or not. I could create an add-on to another accounting system. I may have a new feature that no other accounting system has. Or I could integrate with the CRM system. Thre is no a priori “good practice” I can use to determine the right decision in these cases.

Even the decision about whether to go into accounting software is complex. There are many accounting packages already, but not every vertical has their own package, and not everyone is happy with what they do have. Perhaps there’s an opportunity in mobile. And with some of the new ideas like “thick value” maybe we even need to move accounting from the “simple” domain to the “complex” domain itself. 

The point is that even for this simple discipline, creating software is complex. Each of the decisions I make has an impact on the decisions I made before and the decisions I make in the future. There is no right answer, and there is no best practice, and there is no good practice.

Given all this uncertainty, how do I decide what to do? Well, I make small experiments. In Cynefin these are called “safe-to-fail” experiments. In Lean Startup they are called “minimum viable product” or MVP. (Many people misunderstand the concept of the MVP, although Reis is very clear in his book what it means – the smallest amount of work necessary to test a hypothesis about the business. Compare this to Cynefin’s safe-to-fail experiments – “I can afford them to fail and critically, I plan them so that through that failure I learn more about the terrain through which I wish to travel.”)

The point is exactly the same. I have a question and a hypothesis about the answer. I need to to test it without committing too much effort. And I’m prepared to respond differently depending on the answer I get. 

The testing reduces uncertainty. The next phase in the Lean Startup is “Learn” – which is much like the “Sense” phase of Cynefin. “Let’s make sense of this result we just got.” How does it change or improve (or reduce) our understanding? Is our product concept still good? Do we need to change our focus? In the Lean Startup the change of focus is called a “pivot.” In Cynefin the response is called a “response” – and can be a pivot-like move, or a continue-moving-forward-type of move.

It doesn’t “matter” if Lean Startup and Cynefin are related or not. What’s interesting is that they seem to be saying something about complexity and how to handle it. And what they’re saying applies to product planning and product management, which is what I’m interested in. And it suggests reasons that product planning software has been so deficient in the past – it doesn’t understand that it’s trying to automate a complex domain.