How to choose the right martech stack for purpose-led organisations

Why this article

In my first article, The martech strategy gap: Why purpose-led organisations need more than new tools, I made one case above all others. When we’re thinking of martech I always advise to start with the change you want to make, then design the tech and data to deliver it. This is the practical follow-on. If the first article was about the thinking and approach, this one is practical steps to building.

I've spent years helping organisations untangle their marketing technology. The pattern is often the same. Tools are bought in silos, which cascades two separate challenges. Firstly, the investment for integration, and then the tools get bought around the organisation similar jobs leading to lots of duplication.

This article walks you through that method, step by step. How to audit what you already have, turn what your audiences and teams need into requirements, decide whether to buy or fix what you've got, and build a stack and roadmap that deliver the change you want.

What is a martech stack?

A martech stack is the ecosystem of software, data, and digital tools an organisation uses to build, manage, and deliver audience experiences.

Rather than just a collection of software, a well-designed stack connects your front-end channels to your back-end data, meaning your teams can work efficiently while delivering seamless, personalised journeys. The goal isn't to accumulate tools, but to assemble a connected, adaptable toolkit that directly supports the experiences you want to create.

Does your organisation need to buy a new martech stack?

Not always. Often, the honest answer many martech vendors wouldn't want you to know is that the tools you have can do more if they're configured and connected properly.

If you’re like me, to make sense of things I think in analogies. Reflecting on our work with many organisations the most helpful one I’ve thought about is thinking about your Tech like a garage. You open the garage door, and it tends to be obvious which one your organisation is in!

You open your garage door and find...

If any of that sounds familiar, here's how to diagnose where you are, build a clear picture of what you actually need, and get there.

Step 1: Look in the garage (the real garage). Audit before you buy

Before choosing anything new, understand what you already have, how it's being used, what people like and dislike, and where the pain points sit.

Do this across the whole organisation. Going team to team - whoever is directly or indirectly in an external facing experience will have some kind of tool, and depending on your governance, these tools can be hidden.

For example, we worked with an organisation that had 50 officially approved tools displayed on a very neat architecture map. Once we spoke to different teams and asked the right questions, the real number was five times that. This is called ‘Shadow IT’. You may approach some resistance for teams being attached and protective over their tools, so doing this in a transparent openly communicative way is essential. 

Mapping tools landscape properly exposes every tool in the organisation, and it informs your requirements. 

Two approaches work well, depending on what you're trying to see.

1. Capability and lifestage mapping.

Use this when you suspect the issue is too many tools.

Lay out each stage of the audience lifecycle, then map every tool your teams use against those stages, team by team, and by use case. It's often the first time an organisation sees, in one place, just how fragmented the picture really is.

2. The spaghetti diagram.

Use this when you suspect the issue is integration.

Map every tool, and every connection between them, including where one doesn't exist. Where data doesn't flow automatically, draw the line as a dotted line, to show that data does move, just manually.

Get in touch if you'd like our capability and lifestage mapping and martech spaghetti templates to use in your own audit

Whichever approach you use, colour code what you find. Green for tools working well and fully used. Amber for tools that are underused or partly connected. Red for tools that are duplicated, disconnected or barely used at all.

It's also worth sending a survey across the organisation, followed up with interviews, to ask teams about their pain points (what annoys them), what blocks them (what they literally can't do), and where the bottlenecks are (what slows them down). Capture how much time each week goes into manual work too. That number tends to make the business case for you, and there's more on that later.

Step 2. Internal requirements

Both audit approaches and the survey end up in the same place.

Translate what you've found into requirements of what to change, ranked by how much negative impact they're having. For example time lost to manual work matters more than a mild dislike of a user interface.

That gives you a clear list of gaps, problems and opportunities, which then become requirements.

We use a simple format. A tool must do [this thing], so that we can do [this thing].

Keep the list organised by purpose, by what each gap is stopping the organisation doing, and by how much it damages.

Step 3. Get the audience in the room

This is a step most forget, and for me, the most important. It's also a stage where you usually don't mention anything to do with technology or data.

The outcome here is to paint a clear picture of what your audience actually seeks from an experience with you, then ask honestly where you're falling short, and what needs fixing to close that gap.

Step 4. Turn audience experience ideas into technical requirements

The job here is extracting ideas from the previous workshop into a technical backlog.

For example, take the idea of thanking someone properly after they act. To do it well, you need to understand why they chose you. That single idea becomes a recommendation to capture the motivation at the point of entry, append it to their record as a segment, and build the ability to change the thank you message dynamically to reflect it. One idea, three requirements.

At this stage you may have far more ideas than expected, and that's a good sign. Sort every requirement into must have, should have or could have, checked against the outcomes you defined. Interesting but non-essential ideas, with small likely impact, become a could have.

Reach out if you want our requirements shopping list template.

Step 5. Decide - Do you need to buy, or build it differently

Every requirement needs to be asked one question before anything else. 

Can your existing stack do this requirement if you used it differently, or configured it properly? If yes, don't touch the tools yet. Fix the configuration first, and ask honestly. Why haven't we done this already? What actually needs to be different for this to work this time? 

If nobody can answer either question, the requirement needs more thinking, not a vendor.

Step 6. Score vendors against your requirements

If the answer is no, and your existing tools can't do what you need, move to vendor selection. Sort every requirement into must, should or could, and weight them accordingly.

A vendor selection template we’ve created  has a system where + 10 points for a must, 5 for a should, and 2 for a could if the vendor meets, and deducting points by the same variance if a vendor doesn't meet. Score every vendor against the same list, and the shortlist builds itself, instead of coming down to whoever gave the best demo.

If you want a copy of a vendor scoring template - please get in touch! 

Spotlight on: All-in-one tools or a combination of best in breed?

Once you know what needs replacing, you'll hit this question. Main course, or tapas? (Or am I just hungry writing this).

 Do you consolidate onto one platform, or keep specialist tools and integrate them? As a general approach, we lean towards composable, so your stack can evolve as you do, without locking you into one contract.

Ultimately, it depends on your requirements and preferences. Here's some guidance for how to weigh up the decision.

There's no universally right answer. Organisations with a dedicated data or ops function tend to get more value from the best of breed. Smaller teams usually get more value, and less risk, from consolidating.

Step 7: Build a compelling case for digital  investment

Investing in marketing technology gives you three types of value.

• It frees up your team's time to do what they need to do, more easily and efficiently.

• It consolidates your tech and tools. This matters most if you're dealing with a sprawling garage of tools you've collected over the years.

• It improves the audience experience. The main levers of increased value are people engaging more, coming back again, and staying longer.

We've built what we're calling, for now, the Opportunity Calculator (it needs a jazzier name). You give us some data about your organisation, and using industry benchmarks it estimates what the opportunity could be worth.

Step 8. Build the integration and change martech roadmap

Look at sequencing and cost realistically, and stagger the change rather than trying to do everything at once.

The roadmap is a change plan. These roadmaps should not be technology and data alone. They should identify the different work needed to make it happen. Redesigning the journeys to go live in the tool, which should happen first. Rethinking the content for a personalisation opportunity. Redesigning the business processes and policies. Collecting, storing and activating data differently. At manifesto we use our Connected Framework to identify all the changes required across these themes.

Get in touch if you want the roadmap template 

Lessons learnt, so you don’t have to 

1. Build interventions into your roadmap so you don't end up back in a sprawling garage in a few years. This takes governance as much as it takes technology. We see real value in martech product owners, the bridge between what teams need, the experience you're trying to enable, and what the technology can actually do. It's a critical role that's often missing, and its absence is usually where opportunity gets left on the table.
2. Build momentum and show impact early. Prove return, test, get some personalisation live, and demonstrate value quickly. Find the moment in the audience's experience that's currently losing you the most, and put an intervention there first.
3. Measure whether it's actually working. Buying and connecting the right tools is only half the job. Skipping the measurement step is exactly how tools end up unused for years without anyone noticing. Keep it simple and tie it back to the audience it's meant to serve, rather than the system it lives in. Track whether teams are using a tool, whether data is flowing the way it's meant to, and whether the experience on the other end has actually improved. A dashboard full of uptime and login counts tells you the technology is switched on. It doesn't tell you whether the person on the other end got a better experience because of it. Review this on a schedule, rather than waiting for something to break. A quarterly look at what's used, what's connected, and what's drifted back into a workaround is enough to stop the sprawl creeping back in.
4. Don't underinvest in change.McKinsey found 70% of organisational change efforts fail, and change management is the main reason.

This is the part that gets skipped, and it's the part that decides whether any of the above actually works. Two things make or break a martech project more than the technology itself. The first is change, and it needs saying three times because organisations consistently underestimate it once. Change, change, change. A new system rarely fails because the tech was wrong. It usually fails because nobody planned for people needing to think, work and hand things over differently, and nobody budgeted the time or support for that shift.

That figure holds up across sectors and types of change, from restructures to technology rollouts. In martech specifically, one recent study found a third of implementations either fail outright or land with no measurable impact, and nearly half of failures came down to teams pulling in different directions rather than the technology itself.

The organisations that get it right share a pattern. Senior leaders get involved in vendor selection as well as at sign-off. They invest in training after go-live as well as before it. And they move fast. Implementations that reach a return on investment within six months succeed at almost double the rate of ones that drag on. Momentum protects a project. Delay lets doubt and workaround habits set back in.

Kotter's change model (a manifesto favourite), is a useful framework here, because so much of what derails martech projects has nothing to do with the technology. It comes down to whether there's a shared and honestly felt sense of urgency, whether the right people are aligned rather than nodding along in the same meeting, and whether anyone paused to notice what a team stands to lose, in autonomy or familiar ways of working, before asking them to adopt something new.

Where to start, based on your maturity

Most organisations we work with sit somewhere between early and developing. That's simply the starting point for the audit.

Thoughts to finish

The organisations that get the most from their technology treat quality of experience and ability to deliver it as two sides of the same coin.

A brilliantly designed journey the technology can't support stays a nice idea on a Miro board. Brilliant technology behind a poorly designed experience is just an expensive system nobody enjoys using.

The organisations that get this right treat their tech and data project as part of the same effort as their experience design work. They ask a harder question. Have we actually agreed what the outcome looks like as a whole, or are we hoping the pieces come together on their own once each workstream finishes?

That's the prize. People who feel known and well looked after wherever they meet you, and teams who spend their time on the relationship instead of the plumbing behind it.

Design the experience you want for your audience. Then let the tech and the data enable it. That's the thinking we bring to every martech project.