Strategy first: Designing implementations around what matters

Strategy first: Designing implementations around what matters

DHM Team
9 June 2026
Mixed race group of people meeting to brainstorm an issue in a creative office.
Mixed race group of people meeting to brainstorm an issue in a creative office.
Mixed race group of people meeting to brainstorm an issue in a creative office.
Mixed race group of people meeting to brainstorm an issue in a creative office.

Strategy first: Designing implementations around what matters

DHM Team
9 June 2026

When organisations come to us, whether they’re implementing Salesforce for the first time, rebuilding a marketing technology stack, or trying to work out why a platform they’ve invested in significantly isn’t delivering, the presenting issue is almost always framed as a technology question. Which platform should we choose? How do we set this up? Why isn’t this working?

These are reasonable questions. But they’re rarely the right starting point.

The real question is always: What are you trying to achieve?

You’d be surprised how often that question doesn’t have a clear answer when we walk in the door. The conversation jumped to technology before the business case was fully formed. A platform gets selected, an implementation begins, and somewhere along the way the original goal gets lost in the complexity of the build.

That’s where things get expensive. And not just in dollars.

We’ve walked into organisations that have spent eighteen months and significant budget implementing a platform that works perfectly and delivers almost nothing, because nobody stopped early enough to ask what success was supposed to look like. The technology did exactly what it was configured to do. It just wasn’t configured around anything that mattered.

Our approach: Outcomes, process, technology, in that order

We approach every engagement the same way regardless of size or complexity.

Business outcomes first
What does success look like, specifically? How will we know when we’ve got there? What does the business need to be able to do that it can’t do right now? These questions sound simple but they take real work to answer well. Vague goals produce vague implementations, and vague implementations produce disappointing results.

Process second

What needs to change about how people work, how data flows, how teams collaborate to make those outcomes possible? This is often where the most valuable thinking happens, and it’s frequently the step that gets skipped. Organisations are understandably eager to get into the build. But an implementation that automates a broken process just produces broken outcomes faster. Taking time here saves significant pain later.

Technology last 

Technology is central to everything we do, and it should be the enabler of the first two, not the driver of them. The right technology for your business is the one that fits your outcomes and your process, not the one with the best marketing or the most features.

What this looks like in practice

When a new client engages us, we don’t start with a system audit or a technical scoping document. We start with a series of structured conversations designed to get underneath the presenting problem.

What are the business goals this investment is meant to support? What does the current process actually look like, and where does it break down? Who are the people this needs to work for, and what does their day look like? What has been tried before, and what happened?

These conversations often surface things that change the shape of the engagement significantly. Some examples:

A client who comes to us wanting a new automation capability discovers that their data quality issues will undermine any automation they build.

 A business planning a full platform migration realises that a more targeted implementation of what they already have will get them further, faster. 

A team convinced they need more technology finds out what they actually need is a clearer process and better adoption of what’s already in place.

None of these are conversations you can have after the build has started. They have to happen first.

The cost of skipping the strategy

The organisations we see struggling most with their technology investment share a common pattern. They moved fast with a vendor who was ready to go, a timeline that felt urgent, and a sense that getting started was more important than getting it right.

What they end up with is a system that technically works but doesn’t get used, or gets used in ways that produce unreliable data, or requires constant manual intervention to fill the gaps left by a build that didn’t account for how the business actually operates.

Unpicking that is harder and more expensive than doing it right the first time. And it erodes confidence in the investment, which makes it harder to get buy-in for what comes next.

The irony is that slowing down at the start almost always speeds things up overall. An extra two or three weeks of strategic clarity at the beginning routinely saves months of rework at the other end.

What clients notice most

The feedback we hear most often isn’t about the quality of the build. It’s that we asked questions nobody else had asked. When a client comes to us with a preferred solution already in mind, our job isn’t to validate it and get building. It’s to understand why, and to make sure the approach they’ve landed on is the best path to their goal. Sometimes it is. Sometimes there’s a better way that only becomes visible when you look at the problem from a different angle.

It’s not a conventional way to run a consulting engagement. But in our experience, it’s the one that produces results that actually last.

What this means for you

If you’re evaluating a platform, planning an implementation, or trying to work out why your current setup isn’t delivering, the most useful conversation to have first isn’t about the technology. It’s about what you’re trying to build, and whether the path you’re on is the fastest way to get there.

If you’d like to start with the right questions, that’s exactly what we’re here for. Let’s talk.

InsightsRecent Articles