Our reflections from UKGovCamp 2026
Read more
View all insights
The “solution-first” survival playbook from GovCamp 2026
This post provides a summary of a playbook designed for Product Managers, Delivery Managers, and Designers who have been handed a solution rather than a problem. It was developed from a workshop led by Oli at UKGovCamp 2026, and attempts to pull together the shared wisdom and experience of those who attended.
Many of our clients are familiar with the challenge of being handed a solution by a stakeholder, without first having the chance to determine whether that solution aligns with any real outcomes.
That solution might be to build a dashboard, or roll out a Beta before the quality of the Alpha has been determined. Increasingly, it’s to create an AI tool to increase efficiency.
While the stakeholder’s proposal often stems from a valid goal and may contain part of the solution, accepting it without scrutiny - and risking the delivery of a project which fails to meet outcomes for users - is dangerous. At worst, it ends with something like the Horizon scandal. At best, it’s a situation where teams sink money and team effort into a project that may or may not deliver any value.
Being able to constructively challenge and test that solution against actual outcomes enables you to de-risk delivery, reduce your chances of wasted resources, and increase your chances of delivering real value for users - at your first attempt.
This “solution-first” survival playbook, developed in collaboration with attendees of GovCamp 2026, offers a guide to help you do that.
The "Solution-First" Survival Playbook
Phase 1: Assess your environment
The specific reason that the stakeholder has come to this solution will determine the best course of action. So before you act, identify which "Solution Trap" you are in.
The Vanity Trap: The driver behind the initiative is to avoid missing out on AI, or to look innovative.
The “I’ve Already Done It” Trap: This might be a request to find a use for an existing - and un-used - piece of work, or digitise a process that won’t work digitally.
The Policy/Procurement Mandate: Rigid governance structures often force teams to define the final deliverable upfront, even when the result might be failure.
The “Someone Already Solved This” Trap: A senior stakeholder offers a solution and provider, with the - often false - assumption that this solution can be seamlessly adopted and integrated.
Phase 2: Focus on collaboration over conflict
Whatever you may think of the proposed solution, it’s best to avoid being explicitly negative. Collaborating - rather than blocking - will reap much better results.
Some tactics you can use include:
Treat the suggestion as a valid hypothesis to be tested, not a mistake to be corrected.
Empathise and acknowledge the pressure they are under to demonstrate progress quickly: "I can see you're under pressure to get this out. Let's look at the fastest safe route."
Acknowledge the request enthusiastically but introduce process checks that naturally slow things down.
Phase 3: Investigate and reframe
The next - and arguably most important - step is to move the conversation from "how do we build this?" to "why does this solve the problem?"
This should either retrofit a user need to the proposed solution, or expose the lack of any user need.
It means asking questions - being collaborative, curious, and politely challenging. For example:
Establish where the solution came from. Is it an ask from a senior leader? A response to a user complaint? A panic reaction?
Foreground the user need: i.e. “if I understand correctly, the goal of the AI Tool is to help users find information faster? Or is it about accuracy?’”
Reposition the conversation around what success looks like, and try to reach a shared definition. This is your outcome.
Prototype as inquiry before committing to a full build: Test the stakeholder's solution-as-hypothesis to get rapid user feedback.
Phase 4: Persuade
Narrative is often more powerful than logic. Use storytelling and evidence to make the risk of the stakeholder’s solution feel greater than the pain of taking your approach.
Ways to persuade include:
Point to historic examples of failure from their proposed solution, and how it went wrong in other contexts.
Draw on evidence from real users or frontline staff that contradicts the stakeholder's assumption. Where possible, have frontline staff and users talk directly to decision makers. This is much more powerful than second-hand evidence.
Focus again on outcomes. Discourage following through with the solution for the sake of doing it.
Recruit an ally who can influence the stakeholder.
Phase 5: Shield using governance
Particularly if the above strategies fail, it may be necessary to make processes the blocker, rather than the team itself.
That might look like:
Weaponising standards and best practice (or the Technology Code of Practice, for those working in government) to enforce need for evidence-based work.
Using formal risk management - adding potential risks to the official risk log - to turn the risk discussion into an auditable and formal process
Using audit trails, compelling decision-makers to sign-off the risk of ignoring the evidence.
The magic of outcomes
If you’re at the receiving end of a solution you’re sceptical of, this process may not feel much like collaboration.
But whatever their reason for wanting to pursue the solution, the stakeholder wants the same thing you do: products and services that successfully meet the needs of users. Bringing the conversation back to outcomes - rather than outputs - puts that shared goal into sharper focus, and enables you to find common ground.
Once you agree on a shared definition of what success looks like that isn’t simply ‘delivering the upfront solution’, you may well find that collaboration happens naturally.
Equally, even if the solution you’ve been handed is a good one, becoming comfortable with the process above will raise the standard of all the work you do, and will help you to consistently deliver better services.
Written by
Oli Lovell
Principal Consultant