The Product Lifecycle & Cynefin
Before reading this, it maybe beneficial to have some awareness to the Cynefin Framework. I would also like to express this post is particularly focusing on Digital products and it extends the work I’ve been documenting around the Product Lifecycle.
General Audience : Product Managers and Developers, Business Leaders, Product Strategists, Project Managers, PMO’s.
The original article is posted here.
Improving Product Outcomes Using Cynefin and a Product Lifecycle
Over the past 3 years I’ve focused on product development and product management relative to their age stage in their lifecycle across many different domains, environments and challenges with varying complexity. The result of this work cumulated into a bespoke Product Lifecycle framework; an enterprise level framework based on key principles and data points.
As we created the Product Lifecycle, we developed a range of Lean Governance principles and data points by collaborating with over 20 enabling functions and understanding what is needed when by different stages of their life to support and grow a product, all of course secondary to continuously meeting the customer needs. Much of this was done through adopting principles and practices from Agile, Lean communities as well as many others. This has been no small feat, in an enterprise of 40k employees over approximately 80 countries.
In the earlier days, whilst developing the bespoke Product lifecycle, it was often misinterpreted as a linear model. I presume this was partially due to the 2 dimensional way its presented. Other challenges arose across the organisation where product development and management practices were already in place. Particular challenges surfaced where standardised ways of working were being advocated, particularly from PMO leaders who perceived changes to ways of working as direct challenges to their existing systems.
Through a combination of habitual behaviour and through the introduction of popular delivery methodologies being introduced, it became apparent few people were applying any context to execution, operations or delivery. A good example of the latter is where some PMO’s adopted “Scaled Agile” frameworks without referencing their domain and context; needless to say there were many large, expensive failures. The incentives were generally about command and control against metrics of outputs as opposed to outcomes.
Although they constantly referenced “Lean” in their systems, there were few connections between waste at a wider systems level of the delivery frameworks themselves. Their reasoning was mainly attributed to the need to standardise, better understand their workforce and control delivery. Its not that these delivery methodologies and frameworks were wrong by design, it’s just that they are not suitable to each domain state, particularly those states which are new or being disrupted in the digital world. Another way to put this, these delivery frameworks were more suitable for domains where there are many more known knowns as they are about scaling efficiencies over responsiveness, as opposed discovering known unknowns and unknown unknowns. There was much room for improvement by sense-making.
Age, Stage And Domain
To overcome the above problem and to help teams at all levels of a business focus on value and outcomes needed at different stages of the product lifecycle, we encouraged by reference domain identification with advocacy to relevant behaviours. The cross section here for us were stages of the product lifecycle against domain/environmental state. Having spent some time researching models, training and investigating the problem I finally settled on the Cynefin Framework as a powerful way to express this and land the point we were trying to make.
The Cynefin Framework provided a supporting solution to sense check recommended product and business development behaviours against the environment and state. This provided a clear advantage when understanding how to work in each state, which changes over time and can be supported by a product lifecycle. To explain this further, I’ve shared the following fundamental points to consider before I attempt to explain our thinking :
- 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
To support the explanation of what I described above, I’ve attempted to illustrate the intersection between a Product Lifecycle and Cynefin. This is deliberately a generalisation and should not be considered a solution for all contexts. What I’m trying to illustrate and emphasise with these examples is that when we begin our product journey, there is often a higher degree of complexity and uncertainty in reference to our collective knowledge of the knowns and the unknowns. Put simply, when searching for a business model we should be exploratory and over time we should aim for repetitive processes, but not attempt to standardise too early. The examples don’t illustrate the introduction and increased complexity when you need to scale, this should take the form of another lens exploring the problem beyond this post. In the following Diagrams, I will be referencing the Cynefin domains, advocating the recommending practices and behaviours.
Please excuse brevity of the diagrams, this blog post is a work in progress. When I have feedback validating its purpose, I will increase the fidelity and refine the diagram.
Knowledge Over Time — Cynefin Domains And The Product Lifecycle
In the above diagram a product lifecycle is split down the middle by search for a business model and executing on a business model. I’ve added the dashed vertical as I believe it’s worth calling out from my own engagements and learnings on this topic that whilst you’re growing, you need to do both. I would also like to point out, the starting points for each of the known/unknown states are illustrative and will vary for each context. For example, you might start with significantly more known knowns, than unknown, unknowns. The trend of each is what I’m aiming to share.
- 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 and need to be discovered. Acknowledging their existence however, is key to advocate the behaviour of Probe-Sense-Respond. Agile and Lean Startup could support this behaviour with a scientific approach. Overtime as more knowledge is acquired, 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.
- 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 Sense-Analyse-Repond. The vast majority of the early stages of a product lifecycle, shown above as the vertical dashed line, will generally benefit from this behaviour. 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 in the diagram. When 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.
Summary
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.
Useful Links
