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.
Cynefin has parallel divergent experiments coupled with a formal and traditional process for non-complex aspects. It is designed to cover a range of activities within an organisation. Whether its software development or not the difference still applies. So you have single iteration in Lean Startup with a company or project focus. Cynefin and F-S-E are part of a wide body of methods and tools and the F-S-E is a small but important part of the wider field
Dave – thanks for the comment and clarification. I think it's clear that Cynefin is a big topic, and I'm just touching on a little bit of it. Mostly I am trying to get across (not to you, obviously, since you already know) that you have to approach a complex domain differently than a complicated domain, and that's been the problem with a lot of product planning/product management tools. Cynefin has added to my toolbox of thinking about what I do, and the beginnings of a lexicon that can be useful to talk about it.