August 6, 2025
Summary: In this second post in our series on the key pillars within our Delivery 360 diagnostic, we look at pillar 2 Intelligence & Adaptation. The Delivery 360 is an independent, evidence-based diagnostic that investigates the full system around technology delivery — not just engineering in isolation. It aims to provide a clear picture of where the issues sit, why they exist, and what to do about them. The Delivery 360 assesses across five key pillars: Identity & Direction; Intelligence & Adaptation; Control & Optimisation; Coordination; and Operations.
While Identity & Direction looked at understanding how well organisation knows what it is building, why, and for whom, this second pillar, Intelligence & Adaptation, is about validating whether the organisation can detect meaningful signals from its market, customers, and product data. And then change what it does in response. This is important: most organisations believe they are customer-informed and data-driven. The evidence is usually less flattering. It's one thing having the data; it's another thing to act on it.
When looking at Intelligence & Adaptation, we typically look across four dimensions: Market Context & Adaptability; Customer Discovery & Research; Data, Analytics & Experimentation; and Outcome Measurement. Together, they show whether intelligence shapes decisions or simply sits beside them.
Let's start with understanding why Intelligence & Adaptation matter. Many organisations build decent delivery machinery. Teams ship regularly, roadmaps move, governance functions operate, and leaders can point to visible output. What is often missing is a reliable mechanism for sensing what is changing outside the organisation - in the market, in customer needs, in technology trends - and translating that into better decisions inside it. When this mechanism is weak, the organisation can execute well and still underperform strategically.
As we have said previously, our overarching approach to assessing technology organisations draws much from Stafford Beer's Viable System Model. To be clear, it's only one of many frameworks we use in our work. For example, for engineering we draw from DORA, SPACE and FLOW models. For product we also draw on thinking from SVPG and others. And for team structure we draw from Team Topologies and others. All of these offer insight into elements of the system. We use the Viable System Model framework to bring all of these things together to understand the whole organisation.
In the VSM, Identity & Adaptation is the part of the organisation that is responsible for looking outward and forward. It monitors the external environment, interprets change, and helps the wider system adapt. To be clear, it's not only about intelligence. Sensing is only half the job. The real importance is whether that intelligence is structurally connected to decisions. A team does not become adaptive because it runs customer discovery interviews. It becomes adaptive when customer evidence changes its roadmap. A leadership group does not become market-aware because it discusses competitors occasionally. It becomes market-aware when changes in the external environment lead to visible changes in strategic direction.
To be honest, the harder part is ensuring the intelligence gathered actually changes priorities, product choices, or investment decisions. In many organisations, it does not. Research exists, dashboards exist, and reports exist - but decision-making continues on instinct, habit, or hierarchy. Failure here means the organisation may not understand its market clearly enough; customer problems are not validated before committing to solve them; and the results of effort after shipping are missing or unreliable.
In our assessment we typically examine Intelligence & Adaptation through four dimensions: Market Context & Adaptability; Customer Discovery & Research; Data, Analytics & Experimentation; and Outcome measurement. Together we use these to determine whether the organisation is informed and whether it can adapt to material changes.
The diagnostic question: Does the organisation understand its market, and can it adapt when the market changes?
Market intelligence is only useful if it is current, structured, and capable of changing direction. Having a view of the market is not the same as having an actionable one. Many organisations maintain some form of competitive awareness - a shared document, an occasional discussion in a leadership meeting, a product manager who tracks a few competitors informally. That is not the same as a functioning intelligence capability. The difference is whether the information is maintained with enough rigour and recency to actually inform a decision when one needs to be made.
In organisations with low maturity here, the pillar is operating with a weak view of the external environment. This is more common than most leadership teams assume. Founder-led businesses often scale without ever replacing intuition with a more systematic market intelligence capability. Fast-growing businesses often rely on momentum as a proxy for market understanding. PE-backed firms can become so focused on internal value creation plans that external sensing becomes secondary. What this looks like in practice are competitor moves arriving as surprises. Or pricing and packaging changes noticed too late. Product positioning is described internally in its own language rather than relative to alternatives. Or leaders make strategic claims that are not grounded in current external evidence
In more mature organisations, market intelligence is not treated as an annual strategy artefact. It is maintained continuously and used actively. Leaders can describe how the landscape has changed in the last quarter, what that means for product and delivery priorities, and what response is already under way. But the real test is adaptation, not observation. A maintained competitor landscape is useful. A strategy off-site is useful. Neither proves much on its own. The stronger signal is whether leaders can point to a recent instance where market intelligence caused a genuine course correction.
When looking at Market Context & Adaptability, we look for clear signals that evidence the capability in the org. For example, is there:
The diagnostic question here is: Does the organisation validate customer problems before building?
The failure mode here is assumption-led product development. Many organisations believe they understand customers because sales teams speak to them, support teams hear complaints, or product managers have a strong view of what matters. Customer proximity is not the same as customer discovery. None of that is the same as structured discovery.
Structured discovery means investigating the problem before committing to the solution. It includes direct interviews, observation, concept testing, prototype feedback, but also a willingness to let evidence challenge the initial hypothesis. Without that discipline, teams do not really know whether they are solving a meaningful problem, for the right customer, in the right way. Sales conversations are shaped by pipeline pressure. Support conversations over-represent acute pain. Stakeholder opinions are filtered through incentives, memory, and commercial context. Useful signals exist in all three, but none should substitute for deliberate discovery.
At lower maturity levels, requests move quickly from stakeholder demand to delivery commitment. Product defines the requirement, engineering receives it, and discovery is either absent or reduced to informal validation after the decision is already made. At higher maturity levels, engineering and design participate in problem discovery directly. Teams can explain what they expected to learn, what they actually learned, and how that changed the decision.
When looking at Customer Discovery & Research, we look for real signals. Typically these will include:
All of this means change. If discovery never changes the plan, it is probably being used as theatre.
The diagnostic question here is: Can the organisation see what happened after shipping, and test what works?
If teams cannot observe behaviour and run experiments, they are still deciding by opinion. This is simply shipping without learning. Organisations can invest heavily in delivery but lack a dependable way to understand what happened afterwards. They cannot say whether users adopted the feature, whether behaviour changed, whether the intended commercial outcome materialised, or whether the original roadmap decision was correct.
To be clear, this is partly an infrastructure issue and partly a cultural one. Without instrumentation, there is no behavioural evidence. Without accessible analytics, the evidence cannot influence product and engineering decisions. Without experimentation capability, there is no reliable way to separate causation from coincidence. Teams are left arguing from instinct, hierarchy, or anecdote.
More mature organisations treat post-release learning as part of the delivery system, not an optional extra. Instrumentation standards exist before launch. Teams know which user actions matter, how they will be measured, and what would count as success or failure. Product managers and engineers can access the evidence directly. They do not need to wait for a separate reporting function to interpret basic usage patterns for them.
And experimentation is often the next maturity step. Mature teams do not just observe usage, they test assumptions. They compare variants, define hypotheses in advance, and use results to decide what happens next. Healthy models are built around clearly defined outcome metrics (see later) and disciplined hypothesis testing, not just running tests for volume. That distinction matters. Activity in experimentation is not the same as learning from experimentation. AI products are raising the bar further. Non-deterministic systems require a more deliberate evaluation model than conventional software features. If an organisation is building AI capabilities, experimentation cannot be informal. It needs explicit evaluation criteria, repeatable test methods, and a way to assess quality over time. Many organisations moving quickly on AI still lack that discipline.
When looking at data, analytics and experimentation we look for:
The diagnostic question: Is the organisation measuring outcomes, or just activity?
Output metrics show whether work was completed. Outcome metrics show whether it mattered. Most organisations can produce dashboards full of numbers. And many of those numbers are operationally useful. But in many cases leaders struggle to tell whether the delivery effort is actually creating value.
Features shipped, sprint completion, story points, and tickets closed all indicate activity. They can help teams manage flow and throughput. They do not tell the organisation whether customers are behaving differently, or revenue is improving, or retention is increasing, or time to value is shrinking. Outcome measurement is about closing that gap. It connects product and engineering effort to a change in the world outside the team. That might mean activation, retention, conversion, expansion revenue, or churn reduction.
The exact metric varies but the principle does not. What's changing. This matters because teams optimise for what they are measured on. If success is defined as shipping, teams will ship. If success is defined as moving a customer or business metric, teams start asking better questions. They challenge the chosen approach, look for lower-cost ways to achieve the same effect, and change course when the evidence says the chosen approach is not working.
At the same time, a common mistake we see is adopting outcome language without the associated outcome logic. This often appears in OKRs where key results still describe internal activity. "Launch the new onboarding flow" is output. "Increase 30-day retention by 15 per cent" is outcome. The OKR framework is not about the issue. It's whether the result of the work changed reality.
When assessing outcome measurement we look for evidence of the following:
When we look at Intelligence & Adaptation through those four lenses, we are better able to validate whether the organisation is learning fast enough to direct delivery effort towards the right problems. We find time and again that here is ewhere the sharpest gap appears between leadership self-description and operational reality. Leaders describe the business as customer-led while teams describe working from stakeholder demand. Leaders describe decisions as data-driven. Teams describe analytics arriving after key decisions have already been made.
When there are problems in this pillar it has a number of effects. It can create false confidence as organisations begin to treat assumptions as established knowledge. They can overestimate the quality of their product choices because the delivery system is functioning smoothly. Good execution distracts from poor investment. And it matters beyond product and technology. It affects capital allocation, strategic responsiveness, and the return on delivery investment. An organisation that cannot sense and adapt reliably will keep spending money on work that is well executed but not justified.
When this pillar is strong, the returns compound:
The core question of Pillar 2 is simple: does intelligence change decisions, or just accompany them? If the answer is no, the organisation may still look competent on the surface. It may ship regularly, run the roadmap well, and maintain the appearance of control. But without a functioning intelligence and adaptation loop, it is likely to be efficient in the wrong direction. That is the practical value of organisational learning. It does not make delivery noisier. It makes delivery more accurate.
Next in the series: Pillar 3 - Control & Optimisation. In this we look at how work enters the delivery system? Is it interrogated and prioritised on evidence and strategic intent before engineering receives it? Read more
A 30-minute call is usually enough to know whether a Delivery 360 would be useful — and what it would look at in your situation.
