Improving Product Outcomes Using Cynefin and a Product Lifecycle.
Age, Stage And Domain
- When innovating or searching for a new business model, you have many Known Unknowns and Unknown Unknowns. These need to be discovered and transferred into Knowns for opportunities to be realised, products to be designed and businesses to have a foundation to grow. When executing in a well known space, you generally switch into a more understood state where there are many more Known Knowns. We divided a product lifecycle down the middle into searching for a business model and executing against a business model as put forward by Steve Blank.
- As you’re growing your business and product, you might have a well established business model with many Known Knowns. However as technology advances around your product, customers being fickle will change their expectations and behaviours over time. Digital products are living, with longer term relationships with customers, and are not simply transactional as products once were some time ago.Therefore some Known Knowns can be temporary and be subjected to change. We expressed this by saying that the processes and principles for searching and discovering value act as an engine of product development, which can be used when you begin to realise when your environmental state changes from Simple to either Complex or Complicated.
- Software is often described as being Complex or Complicated, depending on application and definition of complexity. To further understand complexity and software in a scientific context, I would recommend reading this post from Joseph Pelrine. Referencing this post, what makes software complex in my opinion is the application of software to the complexity of the domain. For instance developing software for a well known repeatable domain such as another e-commerce website is less challenging than for instance analysing petabytes of data in realtime for space exploration for a moving rocket. Software on it’s own doesn’t just define the domain state. What can increase complexity is not just the software, but the required cognition of engineering overlaid by the business needs and environment, customer needs and environment, and the abstraction of requirements and needs throughout the management of the system as a whole. Therefore if software is weighted to be Complex or Complicated, combining this with the environmental unknowns and complexities of communication with abstraction of any organisation leads it to be be more Complex.
- Scaling and standardisation is generally more apt to a Obvious state or Domain where there are a high majority of Known, Knowns and the risks of Unknowns are limited. Despite a range of Scaling Enterprise frameworks and models being advocated and sold, much of what is being argued is for standardisation, transparency and efficiencies. By definition prescribing delivery frameworks at scale with low level ways of working at a delivery level and advocating continuous improvement cultures to learn and change is a contradiction to some degree and one to be aware of.
- A product is not just the entity a customer engages with, but the entire value chain, incorporating all the touch points between a customer and a business. When referencing the Product Lifecycle we include the broader context. This consideration needs to be realised before applying a state.
Product Lifecycle And Cynefin Intersection
Knowledge Over Time – Cynefin Domains And The Product Lifecycle
- Complex Domain : Unknown Unknowns – When you start a new business, product or endeavour, cross referenced with the challenges of a new team coming together in a software domain there are many Unknown Unknowns. Overtime as you work together and discover more about the problem you are trying to solve against the value returned for the business and the value offered to the customer, you reduce the amount of Unknown Unknowns. Some of these are exposed as Known Unknowns to resolve or Known Knowns. It’s important to note that it’s impossible to quantify Unknown, Unknowns, only recognise they exist. Acknowledging their existence however, is key to advocate the behaviour of Probe-Sense-Respond. Overtime as more knowledge is acquired and many of the Unknown, Unknowns diminish (indicative in the diagram). I’ve illustrated a turbulence as a product matures to indicate a changing environment. A product could be maturing on the right side of the Product Lifecycle for many years. Through that time, there will be a variance in knowledge, environment and conditions which will impact the product and business. Shifts in the environment will subject the business to changes it hasn’t prepared for. Agile and Lean Startup methodologies and frameworks generally support this way of working.
- Complicated Domain : Known Unknowns – What I’ve tried to illustrate here is that as you are searching for your business model and learning at a considerable rate, you will uncover many Known Unknowns. The more you explore, the more you will discover. In an earlier part of a products lifecycle where you are learning more about the customers needs, the business needs and the skills and capabilities, you will will capture assumptions that need validation and will work through them. Working through them will transfer the Unknowns to Knowns. This is where Cynefin advocates working practices should Sense-Analyse-Repond. The vast majority of the early stages of a product lifecycle, shown above as the vertical dashed line exists will generally benefit from this behaviour. Agile and Lean Startup methodologies and frameworks generally support this way of working. As mentioned in the Complex example above, overtime there will be a variance in knowledge as the environment shifts. I’ve also highlighted this above. The Unknown Unknowns hit the business or product, they immediately become Known Unknowns, hence the inverse pattern. This is cross-reference to the continuos growth of Known Knowns when they become answered. – Lean Startups Scientific approach to experimentation and true Agile delivery principles can be recommended practices for this space.
- Obvious Domain : Known Knowns – Overtime, Unknowns become known. A product and business will continuously gain knowledge until a product is completely retired. The retirement process itself is still a period of knowledge acquisition and therefore this will always follow an upward trend.There is a point in the Product Lifecycle where development, management and support is known well enough to become repeatable processes. At this point, it’s much less wasteful to recognise this as and act accordingly. Where there are many Known Knowns then following Best Practice to Sense-Categorise-Respond is advocated.
It’s important to note, it doesn’t have to be an all or nothing state as a product matures. You may switch the majority of practices/behaviours but actually have all states active at all times through the product lifecycle. For instance, customer support for a mature product may achieve better results advocating behaviours of Sense-Categorise-Respond, but at the same time enhancements on the product might be very Complicated and therefore development teams would be better applying behaviours which Sense-Analyse-Respond.
When trying to decide on working practices, many leaders, advocates or practitioners are deciding upon chosen delivery frameworks without context to the Age and Stage of a Product Lifecycle and without consideration to the State or Domains. The problem of which is choosing to apply delivery frameworks which might be Sense-Categorise-Respond based to the wrong Domain or State one is in. This could potentially result in catastrophic consequences as you inherit the inability to learn and respond to change which can be the very reason you kill your business. On the contrary you might be searching for Known-Knowns and have practices which emulate the behaviours of Probe-Sense-Respond. This can result in extreme waste and again kill your business or significantly introduce costs.
By spending a small amount of time to understand your domain, you can apply best practices and become more efficient at a systems level. You’re also able to recognise where you are fighting the conundrum above when deciding to scale or introducing scaling frameworks. Can Scaling Frameworks for instance truly Probe-Sense-Respond or Sense-Analyse-Respond? How can you have delivery roadmaps of Unknown Unknowns. It’s key to understand your domain against the Age and Stage of your product lifecycle to ensure that you are setup for success.
The challenge of sense-making in business is often overlooked and it’s a space which I’ve been working on for some time that has been extremely interesting and powerful to invoke meaningful conversations. Over the past few years where I have been focused on developing enterprise Lean governance, we learnt that a powerful activity for product development and strategy was to combine Cynefin with the Product Lifecycle. This helped us understand when to use Lean Startup and Agile practices, when and what to look for and created meaningful conversation to inform ways of working, resourcing, management and delivery. It seems very common that delivery frameworks are chosen without context to the domain you are in; a domain which often changes through a products lifecycle. I hope that this provoked some interesting thoughts and I would really enjoy hearing your feedback.