Recently I delivered a presentation about being outcome-focused when introducing tooling and technology, over merely measuring output. Output tends to target lines of code, task completion and busy work. Whereas a focus on outcomes tends to measure proof-of-value, business challenges being met and sustained user satisfaction.
Citation r/AskVibecoders
Many organisations have spent time and treasure seeking success with AI tooling, yet struggle to attain valuable user and business impact. So measuring and targeting success with AI is an increasing concern. To put it bluntly, for some, their claims and reputations are on the line.
I cautioned against an over-focus on output by citing Goodhart’s Law, which states “When a measure becomes a target, it ceases to be a good measure”. This has been recently demonstrated by the phenomenon of tokenmaxxing.
An attendee asked, how can you promote tool adoption that is not merely targeted by measuring tool sign-ins? Doing so could lead to users just signing in to show apparent usage, but not actually getting value from the tool. It could also be a result of teams being coerced to use a tool, despite their experience that the tool isn’t helping them.
The attendee’s question deserves careful consideration. My recommendation is not to think about metrics initially. Rather to focus on the user problem to be solved, and how that can ladder-up to business impact. Take a product-centric approach which incrementally validates whether the tool is desirable, viable and feasible.
Desirability leads to user behaviour changes. These are the leading indicators that can be measured by repeat usage, user recommendations and user satisfaction. Viability is the consequential business impact. These are the lagging indicators that can be measured by cost reduction, revenue growth and market share. Feasibility ensures a tool can be built, financed and operationalised.
While the DVF framework provides the ‘what,’ alone it’ll fail to address the ‘why’ organisations struggle—the hidden, cultural inhibitors to success. So, for many organisations the near-insurmountable challenge isn’t the relationship between types of metrics. It’s the competing pressures, ill-fitting culture and organisational psychology.
Sadly, many organisations have become so pressure-bound for ROI from AI, or certain leaders are so narrowly focused on resource utilisation, that genuinely addressing user needs and creating business impact is an afterthought.
For many organisations, teams don’t feel safe to push back. Teams silently suffer the consequences of the sunk cost fallacy and commitment bias.
So, organisations shouldn’t only institute disciplines that judge success with the right balance of measures. They need to re-imagine their culture and operations for safe-to-learn innovation that selects for tools that genuinely address user and business needs. Using models such as Westrum’s cultural topologies, culture itself can be examined and influenced.
To understand how AI could be beneficial, many organisations are undertaking a programme of AI proof-of-concepts (PoCs). They’re seeking to demonstrate how such genuinely phenomenal tools could benefit them. I fear this approach is mistaken.
On their own a portfolio of PoCs does not validate whether they’d sufficiently address a prioritised set of business needs. Neither do PoCs validate whether the capability can be integrated and scaled in the field, without duplication or being cost prohibitive.
At best such PoCs are little more than technical demonstrations of a capability. At worst they create distraction, sunk costs and delay.
Introduce discipline
I believe we first need to put technology out of our mind. Instead we need to focus on the problems of customers, colleagues and the organisation. Identify the need before potentially overspending on an AI solution that may go nowhere.
Once there’s common alignment and prioritisation of the problem to be solved, we then need to canvas for possible solutions. Such solutions may not be technological; a solution could be related to purpose, people or process. I often ask whether a problem can be solved without touching one line of code.
Whatever the potential solution, discipline is needed to ensure its given the oxygen (e.g. funding) only if it shows demonstratable promise to sustainably solve the prioritised problem. This represents proof-of-value.
Truthfully, something like only 1 in 10 will graduate from proof-of-concept to become proof-of-value. This is the nature of discovering the needle in the haystack of organisational complexity.
What kind of value?
When assessing a solution, there are a number of frameworks for value. Here’s a couple.
IDEO’s Innovation Trinity
Consider David Kelley’s design thinking framework Desirability, Feasibility, Viability. It checks whether users actually want or need it (desirable), whether we can actually build it (feasible), and whether our business should do it (viable).
Another example is Technology Readiness Levels, which help determine which solutions are little more than concepts, and which actually show value in the field and are not financially exorbitant.
windharvest.com
Conclusion
Many organisations are keen to see value from AI and automation. However, they often take a backward approach of expending talent, capital and time to see what proof-of-concepts stick to the wall. This will likely lead to PoC fatigue, frustration and deepen operational messiness.
Rather than take this solution-first approach, organisations should take a targeted outcome-focused approach. This starts with agreement on the problem to be addressed. Then organisations should institute a discipline of evaluating which solutions are proven to show sustainable value.
Underpin the outcome-focused approach with techniques like hypothesis-driven development and Changeban.
So it’s not so much AI adoption. It’s more outcome-first adoption, which may be achieved with some AI solution.
MIT’s recent The GenAI Divide: State of AI in Business 2025 report states that “The 95% failure rate for enterprise AI solutions represents the clearest manifestation of the GenAI Divide”. It says this is caused not by the quality of the tools, but rather the “learning gap” for both the tool and organisation, and flaws in enterprise integration.
In an attempt to gain efficiencies and innovate, I’ve seen organisations excited to roll out GenAI tools. As the MIT report indicates, they should first fundamentally understanding the systems and people such initiatives are purportedly trying to support.
I believe they ought to do this by first asking leaders to align on the most critical customer & colleagues challenge to overcome, and the business outcomes that are most pressing. Those leaders should then learn how systems, processes and incentives may need to change. Such changes should be explored and measured by trialing different approaches, some of which may utilise technologies such as GenAI.
One reason to start with People is that any technological system will not have the tacit knowledge that exists within and between individuals (thank you John Abram for bringing this to my attention). Tacit knowledge is the practical “know-how” that’s difficult to articulate and rarely written-down. It’s often expressed in an unanticipated manner, and only at the time of application.
For example, consider an experienced salesperson teaching a junior employee. During a sales meeting, the latter will learn through observation, imitation, studying body language, and through anecdotal storytelling. These are too ineffable to be derived through studying employee handbooks, process documentation or through GenAI systems.
So, without adopting this outcome-first and customer & colleague centric approach, I fear many GenAI-led initiatives will be fundamentally flawed. They’ll add to the sorry litany of failed technology-focused transformations. The MIT report bares this out.
So, say no to GenAI solution-first thinking. Instead align on the problem to be solved and give colleagues the right freedoms to improve how they serve their customers, which may utilise technologies such as GenAI.
Don’t create pain by rolling out GenAI tooling based on poorly tested assumptions and expect colleagues to use it. Many will suffer in silence, and use the tool begrudgingly. Ironically it’ll likely add to inefficiencies, not reduce them.
Finally, consider employing visual tools such as Agendashift’sChangeban to place a strong emphasis on knowledge discovery and organisational learning. Collectively learn and measure, rather than assuming then integrating!
Does your team tend to do the right thing, or do the thing right?
Doing the rightthing means that despite any mandated procedure, sanctioned tools or external expectations, the team can choose their own approach to achieve its purpose.
Doing the thing right means that the team adheres to the mandated procedures, use the sanctioned tools and meet external expectations, even if it means it impedes them from fulfilling their purpose.
This article offers a technique that’ll enable teams to examine and potentially improve their balance of doing the right thing and doing the thing right. But first an example…
Example
Suppose a team of housing officers aren’t obligated into following ill-fitting procedures, tools, and expectations. They’ll have the freedom to find the right approach to meet their purpose to support their tenants. They will be doing the right thing. They will be discovering and evolving the right procedures, tools, and expectations to support their tenants.
If they are bound by, or hide behind the use of procedures, tools, and expectations, which aren’t fit for purpose, they will be hindered from fulfilling their purpose of supporting their tenants. They’ll be doing the thing right.
Impact of doing the thing right
Many teams feel compelled to do the thing right at the cost of doing the right thing. Lack of freedom to safely challenge, and potentially disregard, mandated ways of working can result in many suffering in silence. It often leads to poor morale, disillusionment, unmet team objectives, and delay.
In fact, the desire to be seen to do the right thing, even if the practice isn’t mandatory, can lead to unnecessary adherence.
At times the detrimental impact can lead to catastrophe, resulting in public outcry, scandal and suffering. One tragic example is the Liverpool Care Pathway scandal, where many patients in palliative care were reported in the media to have unnecessarily suffered as a result of poorly implemented guidance.
It’s reported that many patients were being assessed as terminally ill, sedated and denied water often resulting in many who might have survived longer otherwise dying prematurely.
A less harrowing, yet universal occurrence in many organisations is the expectation that teams adhere to poor-fitting frameworks and procedures. Often these are deemed by outsiders as necessary. However, these mandates were never, or are no longer, fit-for-purpose. For example an overly bureaucratic governance process, an inappropriate compliance regime mandated by distant policymakers, or an inflexible and protracted product delivery lifecycle.
Overcoming doing the thing right
How can teams overcome the pressure to do the thing right so they can focus on fulfilling their purpose? How can they recognise and challenge ill-fitting procedures, tools, and expectations?
I have a technique that will help teams map and strategise their way towards doing more of the right thing. The technique works by incrementally expanding the boundary of existing local freedoms into the area of external expectations and mandated processes.
The technique recognises that mandates may have originated from a worthy – yet possibly misconceived – desire to manage for consistency, efficiency, and alignment across the organisation.
It also recognises that since organisations need to adapt to change and uncertainty, to be effective, teams need the flexibility to safely experiment with emergent and nonconformist ways of working, which still align with the wider organisational vision.
The technique
This facilitated technique involves the team identifying the interactions, processes and tools they are involved with.
Start with identifying between six and 12 items which are routine team practices. Here are some examples:
No.
Item
Type
1
Working with customer representative
Interaction
2
Implementing the needs of an influential Senior Manager from a different business unit
Interaction
3
Regular customer visits
Interaction
4
New governance process mandated by new parent company
Process
5
Manual document control process with no centralisation or version control
Tool
6
Web-based collaborative documentation tools. Tool introduced by the new parent company
Tool
7
Implementing unquestioned requirements based on a untested solution
Tool
Approximately place each item onto a plot showing the value the item contributes to the team’s purpose versus the degree of control the team has to do the item.
The team could do this with post-it notes so they can be easily discussed, changed and moved around.
Example of item mapping showing the degree to which each item helps to fulfil the team’s purpose against the degree to which the team has a choice over adhering to the item
Finally, referring to the illustration below, categorise and discuss the items as follows.
Item Mapping
Team considerations
Low value & team’s choice
Discuss whether the item should be stopped. This item provides little value and the team has freedom to discontinue it.
High value & team’s choice
This item should be continued, monitored and refined.
High value & no team choice
Although the item is mandated, it still provides value to the team. It should be continued and potentially refined with those mandating the item.
Low value & no team choice
Since it’s mandated, the team will need to continue this item. However, where possible, they should discuss with those mandating the item that it provides little value to the team’s purpose. Both parties should explore how adjustments or alternatives could address their shared needs and concerns.
Categories of suggested team discussions.
Next steps
The team should recognise this is a dynamic landscape, over which they have some agency. Therefore this technique should be done periodically, and with discipline. It will help the team continuously expand and improve upon the procedures, tools and expectations needed to fulfil their purpose.
Final thought
This technique should help the team gain a better awareness of the procedures, tools and expectations they have control over, and which they don’t. It will help move from frustration & dejection to engagement & continuous improvement.
Contact me (dean@latchana.co.uk) if you would like help introducing this technique within your organisation.
This workshop introduces Wardley Mapping as a technique to understand the chain of components an organisation needs to serve user needs. It creates situational awareness by mapping the maturity of each component, and the visibility of the component to the user. It allowing organisations to better strategise and improve their effectiveness and competitiveness.
The workshop can be delivered in 60 to 120 minutes. It’s team-based and can be run for any number of teams.
In this example, mapping helps the CIO communicate the need to embed new activities to increase business agility and innovation.
