The eagerness in putting into practice all methodologies and frameworks considered the most current ones in the product community, may end up deviating us from the actual goal of our work: to create value. In this sense, how Cynefin can help us with this challenge? 

What Is Cynefin? 

Cynefin is a conceptual framework created at IBM (1999) to solve an issue of how decisions were made at the company. It is not a tool per se, but a model to organize our minds, offering clearer and more objective ways of thinking about each problem we face. 

Applying the framework on a daily basis to Product Owners, Cynefin helps with the challenge of handling the flood of ideas, issues, and processes. This way, it is possible to maximize the value of each delivery without feeling lost among so many techniques that come up every year. 

The foundation of the model is the division of issues into four main quadrants: obvious things; complicated things; complex things; and chaotic things. There are other nuances as well but, in this article, we will focus on the four main quadrants that can help solve the most latent issues when it comes to the development of digital products. 

Source: https://cdn.cognitive-edge.com/

1. Obvious Things 

When we talk about the quadrant of obvious things, we refer to those that are easy to understand and stable, that is, those that don’t change constantly. The cause-and-effect relationships are simple to understand in this type of issue: when making the right decision, we know what will happen, because the answer is always the same. For this reason, it is easy to establish a best practice to solve this type of issue, which has a single solution. 

Evidently, we face situations where the person responsible for this issue still does not know the ideal way to resolve it, but there is such a way and it is obvious for those who master the topic addressed. This is the case of industrial processes, such as in a soda manufacturer, for example. Each part of the process is known and can be repeated easily. 

2. Complicated Things 

If we don’t master our issue but know what we need to search to solve it, we are talking about the quadrant of complicated things. In this area, we put issues with cause-and-effect relationship that we don’t master and, for this reason, need to be analyzed by an expert on the topic. 

Differently from obvious things, there is no single way for us to achieve the desired result; therefore, issues from the complicated quadrant don’t have a single path to follow, but good practices that can serve as inspiration to achieve the goal. It is like in medical procedures, where each case is assessed according to the patient and an acquired knowledge will be applied. 

3. Complex Things 

Complex things are those where the cause-and-effect relationships can only be studied in hindsight. At some point after the event, it may seem obvious, but still wouldn’t be a result that could be predicted beforehand. For this reason, there are no good practices to resolve complex causes; it is necessary to learn patterns along the way to solve this type of issue. 

We can have some knowledge on isolate aspects, but the interaction between parts of the problem will only be understood when we fit each one of these independent variables. When we don’t know exactly what to look for, it is nearly impossible to find references in the topic. This is what happens in studies about climate change or when we face a new disease. The previous results do not guarantee the future results. 

4. Chaotic Things 

On the fourth quadrant, we have the chaotic things, related to events that are so sudden they don’t allow us to understand the scenario before making the decision. It is any completely unforeseen and urgent situation, when we are more concerned with saving lives, for example. 

This is what happens in natural catastrophes or terrorist attacks where, even with specialists on the topic and recommended practices, those who own this knowledge are not available at the exact time the event occurs. For this reason, the people involved need to make the first emergency decisions, trying to contain the situation immediately.

The Adequate Responses 

We are already used to the idea that different issues require different solutions. Proof of it is that we usually suspect when someone presents a simple or obvious solution to an issue we consider complex. Cynefin facilitates organizing, indicating how we should behave when we face the situations from each quadrant: 

• For simple things: first we notice, second we categorize the issue, and then we respond according to the best practice established; 
• For complicated things: after noticing, it is necessary to analyze the issue to select the most applicable good practice; 
• In complex cases, the act of noticing is no longer the first action to be taken, giving way to exploring. In general, complex problems need Product Experimentation, because we need first collect information and then look at pre-existing patterns, before noticing exactly what we will need to analyze; 
• In chaotic events, action takes the lead position. First we take an action to make sure we are not at risk, and then we notice what happened and organize a better response. 

Applying Cynefin in Developing Digital Products 

In the Development of digital products, it is very rare work with obvious or chaotic scenarios. For this reason, we will focus on the Complicated and Complex quadrants. 

Cynefin and Ideation 

In the beginning of the creation of a digital product, we are in a more complex scenario. We don’t know if our idea makes sense, if this is truly what we should be creating to solve the users’ point pains. At the ends, between the complex and chaotic quadrants, we want to have less uncertainty, we aren’t concerned yet with delivering the product. 

At this moment, it doesn’t make sense to discuss productivity and efficiency, we need to talk about learning. Bringing to the reality of a startup, for example, this is the phase when we want to validate the issue and its options of solution. This is why it is so relevant to apply Design Thinking tools, favoring learning, and lean on innovation and disruption theories. Methods related to innovation, creativity and learning are very useful in this phase.

Cynefin and Validation 

As we move towards a less complex and more complicated scenario, we achieve the moment of validating the product-market fit. In other words: evolving aspects of the product that make it fit the market we want to reach. Here, it makes sense to use methods that are no longer as open, but still absorb changes and adaptations, supporting learning about the experiments we are conducting. 

It is the case for us to use Scrum or other Agile Methods. It is important to remember that we probably wouldn’t be able to use these methods in previous phases, because when we don’t know where to go, our efforts to structure work will probably not bring the result expected. 

Cynefin and Fine-Tuning 

Once the complicated field is achieved, it is time to use more analytical methods, which will allow refining the solution. Only then we will get truly concerned with scale and support of the app, system or platform. We go from a Product Experimentation mindset to focus on a System Analysis or Software Architecture mindset, where we look for best practices to handle defined issues. 

However, we know that currently products never achieve stability. Even after achieving scale, and having the feeling that some parts are stable (complicated domain), new ideas, challenges and business opportunities will continue to arise to enhance it, taking us back to the complex universe. 

Cynefin and Context 

Using Cynefin to organize the issues we need to solve does not mean trying to fit our entire product into a single quadrant. Some parts of our solution may be complex and others may even be obvious. 

Also, when we talk about the Development of Digital Products, we have different perspectives about the same issue – some parts may be simple from the business standpoint, but complex from the technical or usability standpoint, and vice-versa. 

Cynefin is also contextual. That is, a situation that is obvious to one person may be complicated to another person. When we work with a field of knowledge that is completely different from what we are used to, an issue may have a simple solution, but we don’t know it yet – it is not in our repertoire. In this case, we need to resort to a specialist who helps us create an analysis for making decisions. 

How To Apply Cynefin On The Product Routine 

The discovery work starts with an input: an issue, a difficulty, an idea, etc. From then on, the product team must try to frame the situation in Cynefin, to be able to select the most adequate tools. This is roughly divided into: 

• High uncertainty of value, business, usability or feasibility – methods that focus on learning; 
• Medium uncertainty of value, business, usability or feasibility – methods that focus on Product Experimentation; 
• Low uncertainty of value, business, usability or feasibility – methods that focus on analysis, supported by best practices; 

The techniques to be used greatly depend on your context and on what you already have on your toolbox (background). On the table below, we classify some tools to help materialize this proposal: 

For example, if we are in a scenario where we want to solve a user’s issue, but do not have in-depth knowledge about it and don’t know what the best solution is to resolve it, our value risk fits the Complex quadrant from Cynefin. For these cases, therefore, Product Owner (PO) and Designer will need to choose techniques that favor, first and foremost, learning, such as qualitative in-depth surveys (interviews, observation). 

The Best Method For Each Phase 

The main goal for using Cynefin in decision making is enabling the product person to understand not only the best methodology for each phase but also have peace of mind about why applying or not applying each tool. It is important for us to be aware of the context and perspective we are working at; otherwise, we may make completely unproductive efforts. 

Without this thinking structure, we risk applying theories and frameworks only because they are trendy: something that makes us, product people, suffer greatly is the glamorization of some tools, believing that there is a separation between innovative methods and outdated practices that no one else should do. The idea of Cynefin is precisely to bring this rationale that there are no glamorous tools but different techniques for every type of situation. 

Are you unsure about which techniques to use in the creation of your Digital Product? Contact us, and our team of specialists will help you!

O post Using Cynefin to Create Digital Products apareceu primeiro em SoftDesign.

In the corporate world, the term appears frequently and refers to various areas. But at the moment, culture is mainly associated with one particular area: the product area. That’s why we decided to look into this topic to understand the impact of a product culture in startups and companies and learn how to build it.

First Things First 

So what is product culture? It is a set of habits, values, and beliefs that foster the development of digital products. It is characterized by the formation of autonomous teams focused on achieving business goals through the creation or evolution of products. It is an essential prerequisite for the development of contemporary digital products that meet the needs of users and offer added value to clients.

As a culture, it is pervasive. It must impact not only people’s mental models, but also the company’s processes, artifacts, and tools. For example, product culture must reflect the way people are recognized, how success is measured, and even how contracts are signed with clients.

To facilitate understanding, it is sometimes easier to explain what something is not. In this sense, we can say that product culture is the opposite of project culture or IT culture.

Product Culture X Project Culture 

Project Culture, also known as IT Culture, is focused on outputs, while Product Culture is focused on outcomes. This means that, in Project Culture, success is measured by the delivery of scope, of a list of pre-defined items. In Product Culture, success is measured by the impact generated, regardless of what was done or how many items were delivered. P.S. To know more about this difference, it’s worth learning about the initiative No Projects. 

On the other hand, Product Culture is a term created by Marty Cagan. He describes the mindset where IT is paralyzed in operational, everyday processes, without realizing the importance of innovating, delivering value and impacting all the business. If you follow our articles, you know that we usually refer to this phenomenon as tasking IT. 

Those who work in Product Culture don’t usually say they work “in IT.” These people usually refer to the product or business process where they operate, even when they are programmers. 

The Central Role of User Experience 

Working with User Experience (UX) is creating a product and thinking about it from the user’s standpoint. This may seem obvious, but the truth is that the exercise of thinking like someone different from us is challenging. 

What does it have to do with Product Culture? The concern with UX is one of the symptoms of the transition from an IT Culture (self-centered) to a Product Culture (centered on the user). After all, those concerned with generating real business impact certainly need to try to improve the experience for people using the product, not simply “push for” a new solution. 

Also, in Product teams the Designer is not the only one concerned with the Product Design: all members should be aware of the user’s needs and of each of their touch points with the product, to make sure that all details are aligned with its purpose. 

Experimentation to Validate Hypotheses 

Another symptom of the transition from Project Culture to Product Culture is the adoption of Product Experimentation. In Project Culture, it is not usual to save space for learning since the underlying philosophy is a predictive rationalist approach. We define a detailed scope early, and then it is necessary to make sure it is delivered. 

But innovative products, services, or business models are only innovative because they don’t exist yet. This means that they are based on hypotheses and need to be validated, and, therefore, Product Experimentation is essential. In Product Culture, it is necessary to be open to constant learning, changes, and diversity of hypotheses. 

As much as surveys and interviews are conducted with users, collecting information to support development, what we do when defining the product is a proposition, a hypothesis of solution. It is necessary to test quickly and efficiently to learn and discover whether the user experience and the business model proposed effectively work. This is what the Minimum Viable Product (MVP) is used for. 

The Sense of Ownership 

A true product culture only exists when people on the team have a sense of ownership. After all, who cares more about a company than its creator? The idea is that the entire team acts as owners, and therefore truly cares about the product.

People who care build, collaborate, improve, and help define. They have a future vision for the product, are proactive in anticipating and solving problems, and work with enthusiasm and passion. Ownership is responsible for the pride the team takes in working on the product and contributes to quality and commitment.

Metrics to Mesure Success 

Another characteristic of the transition from a Project Culture to a Product Culture is the way of measuring success. Instead of measuring by the execution of plans from the classic triangle scope, cost, and time, we start analyzing by business-related metrics. 

Your taste does not matter much; after all, we currently have many metrics frameworks. In some cases, they will be funnel metrics, in others, your product may have North Star metrics; perhaps your company adopts Key Performance Indicators (KPIs); or also you use Objectives and Key Results (OKRs). 

The important thing is to understand that there is a cultural change. In IT Cultures, people are concerned with delivering what was ordered, within the deadline. Conversations are usually about time or percentage of completeness of the tasks. 

In Product Cultures, the topics are different. The conversation revolves around actual indicators, such as sales, number of clients and percentage of conversions. These figures are no longer secret and are now handled directly by the team that aims at discovering, through experiments, how to positively impact these indicators. 

What is Your Company’s Culture? 

It’s palpable that these terms we have explored are intertwined, right? Product Culture comes as an alternative to Project Culture and IT Culture. It is focused on business-targeted products and users, which need to be validated through Product Experimentation. The team that truly cares analyzes data to assess the success of experiments and evolve the product with agility. 

What type of culture do you see at your company? Notice how people relate with each other (employees and clients), how success is measured, and how processes are designed. Analyzing these items, you will know in which culture your team works and will be able to see the need for a transformation. 

Do you need help to develop a Product Culture in your company? Fill out the form below and our specialists will get in touch with you. 

*Related Content: The 4 Must-Have Characteristics of Your IT Partner

O post Building a Strong Product Culture apareceu primeiro em SoftDesign.