The Best Client Opportunities Begin With A Problem worth solving
Cover image by Francesco Rosati
Some of my favourite work didn't arrive as a request for proposal.
It starts during delivery, usually somewhere quite ordinary. A defect keeps coming back and turns out to be about unclear ownership between two teams. A release slips and quietly shows you where governance has gone thin. A customer journey falls over because every platform involved is individually doing a great job and none of them are talking to each other in exactly the right way. A programme reaches testing for the third time without all of the environments, data or decisions it needs, and you start to wonder why.
I love that moment. A frustration stops being noise and turns into a pattern, and the pattern starts to make sense. Sometimes it leads to more work, and I'm not shy about that, because everything we do has to be commercially viable and it should be. But spotting an opportunity and trying to sell something are different jobs. The question I ask is whether there's a meaningful problem here, whether it's worth solving, and what proportionate help would leave this client in a better place than they were in.
That takes curiosity and a decent amount of judgement, and it's why I find my work so absorbing.
Listen for patterns, not isolated frustrations
Every programme has friction, and not every bit of friction needs a new workstream (I say this with love, and as someone who has been tempted).
The first job is telling a local problem from an organisational one. A test environment going down once is probably just a bad day. Environments failing release after release is telling you something about ownership, planning or platform governance. One badly written acceptance criteria needs a conversation, but the same one turning up across several teams is a clue about product management or quality practice.
The questions I keep coming back to are:
Where else is this showing up, and how often?
What does it cost in delay, rework or risk, and who feels it?
What has already been tried?
What would be better if it were fixed?
Could (and should) the client solve this themselves?
That last one matters more than you might think and can be an odd one for an agency to ask. But asking it protects the client from being offered a large or pricey answer to a problem that they might be better placed to fix with internal decisions.
Test the problem before shaping the answer
It's tempting to meet a visible problem with a packaged service offering. Unreliable releases get a quality transformation, slow decisions get a governance redesign, and misaligned teams get a new operating model. Any of those might turn out to be right, but the symptom in front of you is rarely the whole story.
Unreliable releases might come from weak test automation. They might equally come from unstable requirements, unsuitable environments, inaccessible data, late integration, confusing acceptance criteria or pressure to carry on despite known risks. You can't tell which until you've understood the system around the problem, and I'll admit that's the part I enjoy most.
So a focused diagnostic is often the more responsible first step than mobilising a big team. A handful of stakeholder conversations, a look at the evidence, a few well-run workshops, and time spent watching how things actually work (as opposed to how they're described). What comes out should say what's happening, why it matters and what choices the client has. Discovery earns its keep by stopping us acting confidently in the wrong direction.
Shape around the outcome, not the capability
Consultancies and agencies are full of talented people, and it's easy to start shaping an opportunity by asking who's free or which proposition we could dust off. Every problem is a nail if the hammer department is low on allocation. Buuuut, I'd rather start with the client's outcome. What needs to get better? What evidence would show it had? What do they need to be able to own when we've gone?
A quality challenge, for example, rarely needs one thing. It tends to need a blend of delivery leadership, quality engineering, architecture and platform knowledge, product or service design, operational readiness, data and environment management, and some capability building so it sticks.
I don't need to be the deepest expert on every one of those, and I'd be a bit suspicious of anyone who claimed to be. I need enough breadth to see the systems at play, bring in the right people, and make sure their contributions add up to one coherent answer. That means keeping their work tied to business benefits and to the decisions the programme has to make, and leaving the technical depth to them, because they do it brilliantly.
Work in the Seams
Digital programmes rarely struggle for lack of expertise. They struggle because it's scattered. The CMS team knows the content model, the CRM team knows the customer record, the mobile team knows what the app can and can't do, the application layer team knows what's really possible at the back end, and operations knows what happens once it's live. Each of them can be completely right within their own patch while the customer or internal user still falls through the gaps between the platforms, and the programme with them.
That's where I like to work. It means building shared language across teams who use the same words to mean different things (ask three workstreams what "done" means and you'll get three answers), surfacing dependencies early, and making sure a decision in one corner is understood in the others. A CRM integration choice can reshape the web journey, a scope change on one platform can land on content and training for another, and a squeezed timeline can leave the customer experience stitched together at the seams in the last fortnight. A programme can report green platform by platform while the end-to-end journey is quietly amber. The same goes for the people side, because a change that's obvious to the team building it is often news to the people who'll have to work differently on Monday.
I don't need to be the deepest technical expert in the room to make this work. I need to understand each platform well enough to know where to push: what does this decision change for the people downstream, what does the customer actually experience end to end, what are we assuming another team will pick up, who owns the gap between these two systems, and what will the organisation need in order to run and change this once we've gone? Good questions keep each specialist's work pointed at the outcome the whole programme is there for.
Keep the commercial conversation in the open
There's a difference between spotting follow-on value and creating dependency, and clients can feel it.
A conversation I'd be proud of explains what I've observed and the evidence behind it, how it's affecting delivery or outcomes, and what might happen if nothing changes. It sets out the options, is upfront about the investment and disruption involved, and names what the client will be left with afterwards.
Sometimes the right answer is more consulting support. Sometimes it's a short intervention, a specialist partner, some coaching for the team already in place, or no new engagement at all. I find that being willing to recommend the smaller option builds more trust than almost anything else I do. Clients remember whether you seemed interested in solving the problem or in extending the work, and the relationships that last are the ones where they can see the advice was about their interests and not our utilisation.
Build capability, not an empire
I don't want my impact to depend on me approving every decision, or on a team that keeps growing and can't function without me. The better version is leaving things so that good decisions keep happening once I've gone: clear principles for quality and delivery, defined decision rights, reusable governance and assurance approaches, practical playbooks, coaching for colleagues earlier in their careers, communities that bring internal and external specialists together, and feedback loops that turn what we learn on delivery into better propositions.
I'd rather make good practice repeatable than make myself indispensable, and it's a much nicer thing to have achieved.
It also means staying curious. Automation, cloud platforms, AI-assisted development and changing operating models keep moving the ground, and "it worked on my last programme" has a short shelf life. I want to keep learning from the specialists around me while still giving clear leadership, and I'd say that balance is half the fun.
It all starts with better delivery
The best place to shape new work from isn't a sales script. It's a deep understanding of the client's world, earned by helping them with the problems they actually have. Delivery gives you the evidence, consulting turns it into insight, and commercial judgement decides whether there's something worth pursuing.
Moving between those three is where I'm happiest. It lets me look beyond the task in front of me without dropping it, pull together expertise I don't own, represent a specialism without overstating my own depth, and propose more projects while staying honest about what the client needs.
The opportunity isn't simply more work. It's the chance to leave a client with stronger delivery, better decisions and a bit more confidence than they had when we started, and I never get tired of that.
Originally published on LinkedIn on 2026-10-05. Read the original article
Comments