An exploration of causes, costs and competitive advantages connected to design maturity in product organisations
High‑performing product organisations depend on maturity across all disciplines — design, product management, engineering, data, editorial, architecture. When one discipline is not being fully utilised, the whole organisation suffers, because maturity is systemic. But design maturity is sometimes misunderstood as a craft issue. Sometimes design is equated with usability. But true design maturity expands an organisation’s capacity to work well in uncertainty. So if you want to create the future, rather than just predict it, you need to find ways to achieve design maturity.
Design maturity is more than usability
I’m a design leader, so this matters to me personally. But a lack of understanding and investment in design maturity matters to everyone in a product organisation. When one function is underutilised, the entire system suffers. IDEO defines design as “sensemaking + imagination”. It’s the reason design is such a valuable partner to product management — design extends sense-making into difference-making. Product management excels at sense-making. It synthesises data and combines analytical skills with empathy to make decisions and provide direction — ultimately holding accountability for the success of the product. But without design maturity, an organisation can lose out on the creativity and divergent thinking strengths of design. This comes with costs. McKinsey’s Business Value of Design (2018) found that design maturity correlates directly with financial and product performance.
But many organisations unconsciously define design too narrowly. The dominance of UX has led many non-designers to conflate and confuse the value of design with interaction design, usability and surface-level detail. Even Cagan’s model, for example, places design chiefly in the usability domain. This framing is not wrong for managing delivery risk. But it reduces the perceived scope of design’s contribution. We’ve seen this in the past, when Jakob Nielsen’s early usability heuristics became the default definition of design work in low-maturity organisations.
But thinking of design as solely delivering “usability” within this context is limiting. “Usability” is necessary but not sufficient for an organisation to make the most of design. The result is a reduced role focused on UI, interaction flows, accessibility compliance and removing usability risks. This is all important, but it’s table stakes. When design gets trapped here, the organisation is often limited to incremental change. Organisations that use design only as a mechanism for managing usability risks do deliver safe, predictable, incremental improvements. But they might miss category-shifting ideas. They may also find themselves falling back to stakeholders for direction-setting or executing a HIPPO’s vision, because they’re underpowered in the skills needed to generate, communicate and manage diverse insights and ideas effectively. They’re likely to be limited to communicating vision in logic-biased prose rather than category shifting poetry that design-enabled product management is capable of.
Climbing the ladder…
When a product organisation is immature, design is equated with wireframes, flows, accessibility checks or research to eliminate risk. This work is necessary but insufficient for value creation. The Danish Design Ladder describes how organisations evolve through:
- Non-design — Design is absent or decorative.
- Design as styling — Form-giving, surface-level.
- Design as process — It’s an integrated element of development.
- Design as strategy — It’s a tool for shaping business models and futures.
Most product‑influencer narratives peak at level 3 at best. But mature design can go further: into strategy, systems, and the shaping of opportunity itself.
The Danish Ladder says design will have the biggest impact when it’s deeply embedded in the strategic planning of an organisation. This is because design is a process of translation. Through artefacts, design translates ideas into value-generating products and services. As design undertakes this “translation” it also inevitably transforms ideas, manipulating constraints and capabilities to optimise the design. Design is therefore most effective when it’s able to influence both problem-framing and solutioning at the strategy level. Design isn’t art. It’s a process for solving real problems for real people by understanding them and getting creative to make progress and a positive difference.
When design is only allowed to operate at surface levels, or even when it’s called on to “execute” a strategy, you’re missing out on potential value. To non-designers this point might feel like “discipline inflation.” I get it, we all want to feel important. We all want a seat at the table. We all want to argue that we’re the secret to competitive advantage and need to “hold the pen” on the strategy. I don’t think that’s true for design in every context. The sense-making, convergent tendencies of product management mean that in most cases design shouldn’t be the dominant decision-maker in a product organisation. But they should be included in strategic work — and work that is most ambiguous — for the simple reason that designers are brilliant at having and managing ideas.
Idea management: The missing discipline?
Design is a systematic, creative, opportunity-generating discipline. When organisations misunderstand it as only enabling usability risk-management, they prevent themselves from operating at higher maturity. Organising around risk (value, usability, feasibility, viability) is sensible. But risk management isn’t the whole job. If you only reduce risk, you only reduce possibility.
Designers are trained to expand possibility and enable delivery by moving fluidly between divergence and convergence. A mature design practice surfaces new possibilities from research, signals, or anomalies. It looks across journeys, systems, and time — not just features. It detects patterns that suggest new value. It turns weak signals into opportunity areas. All of these core competencies of a skilled product designer are powerful and valuable — but so far, they’re not particularly unique to design. In some cases, they may even be more naturally suited to the convergent mindset of a product manager. But design does bring something extra. Design is a structured discipline for managing ideas. It doesn’t just detect patterns — it invents new ones. And it turns weak signals not just into opportunity areas, but into articulated opportunities that other disciplines can experience and understand quickly and cheaply to collaborate. Design done well looks like:
- Divergence (exploring many possibilities)
- Convergence (narrowing to the strongest)
- Visualisation (making intangible futures and assumptions visible and testable)
- Iteration (enriching ideas through critique)
- Integration (seeing relationships as systems and experiences emerge)
Let’s look at the impact that this can have in practice…
Three hypothetical approaches
Imagine three different approaches to the same project. The context is high in ambiguity. The market context is highly competitive. To operate effectively the organisation needs to combine multiple talents, each with their own levels of maturity and different cultures. Likewise, the technical landscape is complex with a mixture of technical debt and emerging technologies that few in the team have experience of using. We step into the multiverse and see how three teams might approach the task:
Team A starts their discovery and execution by a PM creating a strong, detailed PRFAQ. It places users right at the centre of a story of the future. This sharpens the narrative across disciplines. It’s an inspiring picture that teams can get behind, so it aligns stakeholders around a single vision. The FAQ section answers the questions that are front of mind. But the document imagines an end‑state rather than discovers one. It privileges linear, verbal thinkers who love prose. It’s like a piece of rhetoric, so it also risks a false certainty.
Team B create a detailed and comprehensive Opportunity Solution Tree (OST). It allows them to multi-track, exploring data and customer conversations to build an abstract map of opportunities. The team attaches data to branches to help prioritise the biggest opportunities and they work along branches, logically validating opportunities and bringing design skills in to generate possibilities. The team works on it together, collaboratively, sharing perspectives and having rich conversations amongst themselves and with users. It encourages exploration before convergence. And it helps the team track evidence and hypotheses together. But it’s weak at representing lived experience or systemic relationships — it’s an abstraction of a problem space. Sometimes the team struggles to navigate the structure of the ever-expanding tree. And it’s hard to hold the whole structure in your head at once. It makes systems thinking, journey‑based context, understanding time and flow harder, because it’s natively hierarchical rather than relational.
Team BBC is led by a skilled leader, experienced in multidisciplinary collaboration including design. They like the multi-tracking divergence and evidence-based decision-making of the OST, but they think that can make it even stronger. They create an Opportunity Service Map. It’s a shared artefact that still operates at an abstract level but brings the product landscape to life — it helps the team visualise experiences before, during and after customers interact with the product. It helps teams understand the experience and the backstage systems that power it. They talk to users, feeding in insight and operating with empathy. The team works collaboratively, as they do with the OST, but now they overlay opportunities directly onto a service blueprint. They’re curious, so they sidestep the “curse of knowledge.” They start with problems and “why” questions, then they move to lo-fi ideation. They work collaboratively using techniques like SCAMPER to explore and refine ideas. Then they prototype — they select the method depending on the concept and what assumptions they need to investigate. They regularly create cheap sacrificial concepts and test with users. Because the Opportunity Service Map shows frontstage, backstage, enablers, time, friction, confidence and impact it connects ideas and assumptions to the reality they operate in. This keeps exploration broad yet situated.
Immaturity in one discipline hurts the whole system
The best teams I’ve ever worked in operate more like Team BBC. Teams A and B exhibit many strengths of an effective product team. But Team A’s design immaturity forces them to execute a vision that is handed to them. When a team uses a PRFAQ to translate customer obsession and insight into action, it’s a brilliant way to ensure decisions in delivery align with a coherent user outcome. But teams first need to be able to generate this insight and have invented a vision of how to meet it. A PRFAQ is evidence of the synthesising power of product management. It can boost accountability and provide a single-threaded leader with a contract to fulfil. But it won’t help you create.
Product management isn’t about managing a static thing — we’re managing not only what the product is and how it’s performing now, we’re often managing what it can and should become in the future. Product teams are responsible for delivery and discovery. Design maturity is so powerful because it introduces comfort and competence in dealing with the ambiguity of invention.
OSTs are therefore a signal of increased design maturity because they help encourage teams to work “outwards as well as backwards” — diverging and multitracking. This looks more like design — moving forwards andbackwards, diverging and converging across multiple tracks, iterating to refine and optimise. Once you add in creating artefacts that act as experiments as you make progress, you see how and where design adds value.
Design helps teams explore from the present into multiple plausible futures before committing to one. An organisation without maturity in design might only ever develop the competence to work backwards from a chosen future or execute with an inherited or fixed set of constraints. With design maturity an organisation is much more likely to be able to blend the talents of product management and engineering with design to work forwards and backwards, manipulating problem-framing and solution-making to help the organisation find the most valuable future, no matter their context.
Modern organisations operate across multiple contexts. Mature product teams know that some work is simple or complicated and work through it accordingly. The most mature teams can also identify and operate in complexity and chaos. To work well in complex domains you need strong, confident disciplines, distributed decision-making and a willingness to explore unknowns.
When design maturity is low, the whole organisation becomes less capable of operating in uncertainty. Product management might end up filling the gap — but you’re likely to have fewer, weaker ideas. Not because product managers and other disciplines can’t have ideas, but because design as a discipline has evolved to manage them most effectively. Each discipline has a core strength and purpose. This is why you need design — because it adds unique and valuable skills and because immaturity in one part becomes immaturity everywhere, as everyone is forced to generalise to fill the gap.
We can look at two helpful models to understand this further. Robert Kegan’s theory of adult development describes how people evolve in their “mental complexity” — their ability to reconcile ambiguity and competing truths. At the Socialised Mind, identity and direction are shaped by the expectations of others. Decisions are anchored in fitting in, meeting external standards and aligning with prevailing norms.
At the Self-Authoring Mind, individuals develop an internal compass. They can understand and appreciate the expectations of others while also generating their own frameworks for judgement and action.
A smaller group shift further into the Self-Transforming Mind, where they can integrate multiple frames at once and work flexibly in paradox, ambiguity and change. Kegan talks about individuals. But I think you can use these stages to describe teams.
A multidisciplinary team mirrors these stages. A Socialised-level team performs competently within the dominant discipline’s worldview (often PM or engineering). They optimise for alignment and predictability — they “organise to execute”. A Self-Authoring team begins to define its own integrated way of working across disciplines by co-creating a shared approach grounded in collective purpose and context — they’re empowered to solve problems. A Self-Transforming team goes further: it can switch modes depending on the problem space — convergent when needed, divergent when needed, exploratory in uncertainty, decisive in clarity — they’re empowered to find problems and invent the future.
Operating in ambiguity demands high maturity across disciplines. The lowest common denominator of people playing multiple roles or the over-dominance of a single discipline won’t work. Strength and maturity in each discipline is required, so that the organisation and its teams aren’t trapped by any one discipline’s identity but can metabolise all of them to meet the moment. When teams mature to this point, they stop behaving as a collection of functions and start operating as an adaptive system capable of solving harder, more ambiguous problems than any discipline could manage alone.
Kegan’s developmental lens pairs naturally with Amy Edmondson’s work on psychological safety and teaming. Edmondson argues that in environments of high uncertainty and high interdependence teams perform best when members can speak up, question assumptions, surface risks, and integrate diverse perspectives without fear. That’s only possible when individuals move beyond the Socialised Mindset and when the team behaves at a Self-Authoring or even Self-Transforming level — able to adapt how it works together.
Building maturity
When design is strong, every discipline benefits. In simple or complicated contexts, disciplines can operate independently and with lower levels of maturity. Product management can set a goal, engineering can implement with rigour, design can ensure usability. But as complexity increases, the future stops being something you predict and starts being something that emerges from interaction. At a certain point, predicting becomes riskier than designing. No discipline has the full picture. You need the exploration, translation and reframing muscles that design brings — finding gaps and opportunities, making ideas tangible, and helping the team update its understanding of the problem, the constraints and what’s possible. At its best, design surfaces opportunities before they calcify into problems, synthesises research into multi-level insights, prototypes to explore strategy (not just UI), and connects journeys, systems and stories into experiences that actually matter. It helps shape direction alongside PM, engineering, editorial, data and architecture — but only when it’s included early enough, high enough and meaningfully enough.
Maturity rarely develops evenly across an organisation. But you can accelerate the maturity of design by involving and empowering designers where ambiguity, opportunity and risk are highest. These are the areas where linear planning breaks down, expertise alone stops being enough, and teams need experimentation, creativity and distributed judgement.
Simple shifts can bring greater design maturity to an organisation:
- investing in framing as well as solving
- intentionally cycling through divergence and convergence
- mapping opportunities into the systems they live within
- critiquing ideas to sharpen, not to narrow — and to build rather than diminish creative confidence
- pairing narrative tools (PRFAQ) with experiential ones (prototypes) and making richer abstractions of opportunity spaces — finding ways to show, not just tell people what the future should be like.
Importantly, these shifts don’t weaken other disciplines — they strengthen them. They help PM and engineering build design literacy without forcing those teams to compensate for an underpowered design function.
Design maturity isn’t about risk reduction; it’s about strategic advantage. It helps organisations spot new value early and gives teams the confidence to pursue it. If you expect your organisation to shape the future, not just survive it, your teams need the maturity to discover, deliver and design what comes next. The future we prefer won’t arrive ready-made — it will be built by the organisations that design it.
Leave a Reply