Some time ago I wrote about why skipping the RFP isn't always an option. The piece opened on a comment Jay Calavas from Tealium had left under one of my LinkedIn posts:

"Skip the RFP and focus on use cases and measurable outcomes!"

I said he was right. Use cases should lead. I meant it, and would say it again tomorrow.

Then I sat down in the next selection and couldn't act on it.

I reached for the requirements template, because, look, it was there and the clock was running. The plan was that the use cases would come out of the workshops later, once everyone had seen the tools and knew what to ask for. They didn't come out of the workshops later.

They never do.

Why would they?

Nobody had the words yet. By the time anyone had the vocabulary to describe what they wanted, three sellers had already spent six weeks describing it for them, in their own words, on their own slides.

That's not a failure of nerve.

It's that following Jay's advice takes something everyone assumes is lying around somewhere, and it isn't.

Why skipping the RFP isn’t always an option and how to avoid the biggest traps

Four practical steps that help teams protect themselves when the process can’t be avoided

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

The advice is older than my RFP series

Scott Brinker made the same case in February 2022, in a piece called "It's not the size of your martech stack, it's your range of use cases".

He put the definition in one sentence:

"A use case is a specific customer experience, with certain functionality, delivered through a particular channel."

He was writing off the back of a Bain survey of a hundred consumer products companies, scored across thirty martech capabilities. The leaders had more than fifty use cases in wide adoption. The laggards had fewer than five. Those figures are four years old and I have not seen the survey itself, so take them as a picture of 2022 rather than a claim about today.

To be honest, a 2026 version would be worth having. Bain, are you listening?

The shape of the finding holds up regardless. What separated the companies doing well from the companies stuck came down to how many use cases they had running. Not how many tools they owned, which is the number everyone reports, and not what they spent, which is the number everyone defends.

Four years on, that one sentence of Brinker's is still the whole shared vocabulary the category has. A specific customer experience, certain functionality, a particular channel.

Now go and score three platforms against that. How far do you get?

Look, I know there are hundreds of these

This is the part where you tell me the lists already exist, and you're right, they do. Braze has one and calls it the Use Case Library. Most of the large platforms run something similar, the agencies have their versions, the consultancies have theirs, plenty of them are genuinely useful, and I've cheerfully sent clients to more than one.

Every single one of them stops where the product stops. No surprise there.

That's not an accusation, and worth being careful here, because this is usually where a piece like this turns into a complaint. Braze wrote theirs for people running Braze. It's the correct thing for Braze to do, and a version scoped to everything Braze can't do would be a strange document to publish.

It be weird for my car manual would give me tips on how to brew a solid coffee.

To be fair, nobody's being sneaky. But a library written by a platform is a catalog of reasons to buy that platform, ordered to suit the buying, and that's a different object from a description of the work.

Put two of them next to each other and it shows up straight away. The same problem picks up a different name, a different scope, a different set of edges. One treats suppression as a setting inside the campaign tool. Another treats it as a question about how audiences get built. A third barely mentions it, because in their architecture it happens somewhere the marketer never sees.

All three descriptions are honest. But none of them can be laid against the other two. And laying them against each other is the entire job when you're choosing between them.

So you end up doing the translation by hand, under time pressure, in a spreadsheet, usually alone. Have you ever seen that spreadsheet survive the second round of demos? Call me when you do.

What actually gets sent out

I've read a lot of these documents. The pattern's consistent enough to guess most of yours.

Six to ten lines, each about a sentence long. Improve retention. Personalize the homepage. Reduce wasted ad spend. Build a single view of the customer, which is less a use case than a wish with a budget attached.

Those are goals, and mostly they're good ones. A goal has no surface though, and you can't test a demo against a surface that isn't there. Ask a platform whether it can improve retention and there's exactly one available response. Yes, followed by forty minutes of screens. What else would they say?

So the seller does the only thing on offer and answers with features, because features are the part of their world you can show inside a meeting. The second one does the same. By the third demo you're back in a grid with checkmarks in it, which is precisely what everybody, me included, told you to avoid.

I used to file that under discipline. Teams knew they should lead with use cases, got busy, and reached for the requirements template instead. And I'd nod sympathetically about process. I was wrong about that. I mean, I did exactly the same thing the moment a deadline showed up (twice, since you ask), which should have told me something sooner.

The discipline's usually fine. What's missing is the thing the discipline was supposed to operate on.

Five things that make a use case comparable

Here's the test I've landed on. It's less elegant than it should be.

A use case only becomes comparable to another one when it names the data that has to exist before anything can run at all. Then the tools, which everyone already writes down, and which matter least. Third, and this one is almost never filled in, who keeps it alive after launch. That field outlives the project and turns into somebody's Monday morning. Leaving it blank is not a small omission. Fourth, the order things have to happen in, which is where most of the interesting disagreement between two platforms actually lives, and where a demo will never take you unless you push. Then how the thing breaks. Not whether it breaks. How.

That last one is worth arguing about. Every use case has known failure modes, and they repeat across every company that has ever tried it, which is why implementations slip on the same rocks year after year. I have never once been handed a requirements document that mentioned one of them.

Write those five down for one use case and the conversation changes character entirely. You stop asking whether the platform can do personalization. You start asking who owns the identity ruleset, what happens when someone withdraws consent halfway through a sequence, and which of your two teams gets the call when an audience goes stale.

Those questions have answers you can compare. And the answers differ, which is the point.

Why did that take so long to write down? No idea, honestly. It had been sitting in plain sight in every project I've run.

Rather than list all five in the abstract, let me run one use case through them.

One use case, all the way down

The one I want to use is called cross-platform, consent-aware post-conversion suppression. Dull name. What it means is you're not paying to advertise to people who've already bought from you.

Some of you will recognize it, because I scored a version of it back in June, in the Context Audit. That exercise looks backwards at a workflow already running and asks how good its context is. This one runs the other way, specifying the thing before it exists. Same workflow, opposite direction of travel, and it's worth seeing both.

The Context Audit

A follow-up to the follow-up. My last piece explaining “what the context layers has to do” argued that customer state has to be Queryable, Addressable, Current, and Accountable if agents are going to act on it in real time. It ended pointing at a one-page audit and

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

Start with the problem, which is more specific than the line that usually stands in for it, which is that retargeting wastes money. You put suppression on Meta, it works, everyone's pleased. Google Display carries on. So does TikTok, so do the programmatic networks. Each of them wants a different identifier format, updates on a different schedule, and expires an exclusion on its own timetable. Then the part that catches people out: under GDPR, suppressing someone is itself use of their personal data for advertising, so consent has to travel alongside the conversion event rather than sitting in a different system entirely.

The outcome is a number. Thirty to fifty percent off retargeting spend on the converted segment, depending how many channels were leaking. You can put that in a business case. You can't put "reduce wasted ad spend" in a business case, which is roughly the difference this whole article is about.

Ingredients come next, and there are five: conversion events, a hashed email identifier, the mobile advertising ID, a consent state flag, and the jurisdictional context that flag sits in. Not one of those is a product, by the way. That matters, because if two of the five don't exist in your business today, no platform on the shortlist can rescue you, and you've just learned that before signing rather than after.

Equipment is the part everyone skips ahead to. You need identity resolution at a workable scale and consent state propagated into a handful of ad platform APIs. In a composable stack that usually lands as a CDP, a reverse ETL layer and a consent management platform, with the warehouse as the source of truth. One paragraph. Genuinely, that's all the tool question deserves at this stage, and look at how much of every RFP it eats.

Then staff, and here's where it gets interesting.

Seven roles. Marketing ops for audience strategy, ad ops for the platform exclusion configuration and the logic that lets people back in, data engineering for the pipeline and the identifier transformation, whoever owns identity for the identifier strategy and decay, legal for consent posture and audit defensibility, privacy ops for consent propagation and right-to-be-forgotten, and analytics for holdout design. Six of those are critical. One is supporting.

Seven roles, sitting across different reporting lines, for the use case everyone describes as the easy one.

The technique field composes six patterns and sets a latency target of one to four hours, with the honest note that batch-only platforms won't hit it. And the gotchas, which is the field I'd read first if someone handed me this document cold, list three ways it goes wrong. Teams treat it as configuration when it's orchestration. Measurement gets fudged, because a before-and-after comparison quietly absorbs seasonality and whatever the ad platforms changed that quarter, and the holdout that would settle it deliberately wastes budget, so nobody wants to run it. And re-introduction logic gets forgotten, so the exclusion pool grows and grows until, a year later, your acquisition reach is worse and no one connects the two.

The field that decides whether it ships

That staff list is the whole readiness question in one box.

Six critical roles across several reporting lines isn't a technology problem, and no platform solves it. If you can't put a name against each of those six today, the shortlist is beside the point, because the thing will stall in the gap between ad ops and privacy ops regardless of what you bought. This is where Structure, Capability and Process stop being a framework and turn into a staffing list, and it's the field that never appears in a requirements document.

The gotchas do similar work at the other end. Look at that last one again. An exclusion pool that grows for a year before anyone notices isn't a launch failure. It's a failure that arrives long after the implementation partner has gone home and the person who set the expiry rules has changed jobs. To be fair, no seller's going to volunteer that in a demo. But you can ask about it, and asking about it tells you more about who you're dealing with than any reference call will.

Try it on one of yours

Take the use case at the top of your list. Seven boxes on one page: problem, outcome, ingredients, equipment, staff, technique, gotchas. Give it an afternoon.

What tends to happen is this. Problem and outcome take twenty minutes and feel productive. Ingredients take longer than expected and produce the first useful argument, usually about whether you actually have a consent flag or just believe you do. Equipment is quick, which surprises people. Staff is where you stall, and the stalling is the finding. Gotchas is where someone in the room says they've seen this before and describes exactly what happened.

Then do a second one, and a third. I mean, three is where it stops being a document and starts telling you something about the business, which is a thing I've said before about workflows and it turns out to hold here too.

So I built the list I wanted

The Martech Cookbook came out of a conversation with someone whose analytics work I've followed for years. He said one thing about use cases that changed how the whole problem looked. The idea was his.

The version that exists is mine, and any dullness in it is mine as well.

It's a reference of Martech use cases arranged by outcome rather than by tool. That's the only arrangement that makes comparison possible, since arranging by tool is what got everybody into this. Each entry names the problem, the outcome, the data, the equipment, the people, the technique and the ways it goes wrong. Kitchen words, because a recipe is genuinely the closest existing thing to a properly specified use case, and because the alternative was calling it a framework. 😉

Those entries are free and openly licensed. No form.

One thing to say plainly, since I've spent two years telling anyone who'd listen that nothing here is gated. There's a second tier on the Cookbook that asks for a business email, and it feeds my Workshop. That's what it's for. Everything else I publish is open and stays open, this is the exception, and I'd rather name it here than have you find it yourself and wonder what else went unmentioned.

Anyway. Jay was right in 2025 and Brinker was right in 2022, and advice that has held up for four straight years while staying unusable deserves better than another article agreeing with it.