Martech tools pay off when they’re hired for a job, a specific piece of progress your team needs to make. Most purchases fill a category slot on the stack diagram, and money spent filling a slot goes to waste when no job was defined.
Key Takeaways
- Most martech tools get bought to fill a category slot. They produce value when they're hired for a job your team has defined.
- Write the tool's job description before the demo: the outcome, the owner, and the signal that says the job is done.
- Job-first buying runs slower than category shopping, and a tool that passes your sample use cases can still miss requirements you never tested.
- A few tools earn permanent roles. Treat the rest as hires whose jobs end, and remake the decision at every renewal.
Marketing buys technology in a unit that guarantees disappointment: the category. A stack gets planned as a set of slots. A CDP goes here, marketing automation there, analytics underneath. From that point forward, the buying conversation is about which vendor deserves each slot. Whether the slot deserved to exist rarely comes up.
There’s a better unit, and it comes from the late Harvard Business School professor Clayton Christensen’s jobs-to-be-done theory: people buy products to make specific progress in a specific situation (1. Christensen et al., 2016). A job, in stack terms, is the progress your team needs, with an owner and a signal that shows it’s happening. A role is the slot on the diagram. Functions are what the software can do. Most buying decisions weigh functions and roles, but a tool produces value only when it’s doing a job.
How martech tools get bought by role
The martech landscape map sorts more products than any team could evaluate into a tidy grid of categories. No team shops that map product by product. As I see it, brand, price, and compliance usually cut each category to a handful of incumbents, and the shortlist writes itself. That efficiency is real. So is its blind spot: every filter in the process works inside the slot, and none of them tests whether the slot maps to work your team needs done.
Feature evaluation shares the blind spot. David Raab, who founded the CDP Institute, points to survey research showing that the buyers most satisfied with their selections chose on features rather than cost, and then adds the catch: no checklist captures what it’s like to use the software for a specific task (2. Raab, 2020). Features are the best of the checklist criteria, and they still describe the function list rather than the work. The job never appears on a feature checklist, because the checklist came from the category, and the category came from the vendor side of the market.
What hiring a tool for a job changes
A job description for a tool runs 3 lines, written before any demo. The outcome the tool must produce. The person who owns that outcome. The signal that tells you the job is getting done.
That document changes the shortlist. Some category incumbents drop off because they can’t run your job. Some categories dissolve because the job turns out to belong to a process or a person, and no software was needed. And when vendors demo , they demo against your job instead of their script, which puts you in control of the sales cycle.
Raab credits Tony Byrne of Real Story Group, an independent research firm that evaluates marketing technology vendors, with the case for defining key use cases and making vendors demonstrate them, and notes that’s a Christensen-style job to be done (2. Raab, 2020).
Calendly rewrote the role into a job
Calendly, the meeting-scheduling software company, had filled the CDP slot with Segment, a packaged CDP, collecting behavioral events from its website, mobile app, and browser extension to power personalization . The slot was filled, but the job it was bought for wasn’t getting done. Marketing couldn’t join those events with the customer data that lived in Google BigQuery, the company’s data warehouse , so the marketing team couldn’t use that data to experiment and personalize (3. Hightouch, 2024). Omar Mayar, whom the case study lists as a senior data engineer at Calendly, called the old setup “a black box” (3. Hightouch, 2024).
The fix was a rewrite of the purchase into a job: get every customer signal into the warehouse, then sync audiences into the tools that run campaigns. BigQuery plus Hightouch, a tool that sends warehouse audiences to marketing apps, now feeds the ad platforms, Optimizely for A/B testing, and Braze for email campaigns. Setup took under a day. The numbers come from the vendor’s own case study, which quotes Darren Chait, whom the case study lists as Calendly’s head of growth marketing, so read them as self-reported: activation from personalized email rose 16%, and CDP costs tied to the number of distinct people the CDP records each month (monthly tracked users) fell 15 to 20% (3. Hightouch, 2024).
Calendly took the job the platform was failing at, modeling and activating customer data, and staffed that job with the warehouse and a tool that sends warehouse audiences into marketing apps. Calendly kept buying in the CDP category, but it chose the architecture by the job it needed done: joining every signal in the warehouse and sending audiences out.
Where job-first buying breaks
Job-first buying is slower. A category shortlist takes an afternoon. Writing jobs takes working sessions with the people who own the outcomes, and procurement timelines stretch to match. Budget for that time, or the process will collapse back to the category map under its first deadline.
The second cost is subtler, and Raab named it: use cases work as a sampling technique, and assuming that a tool passing your sampled jobs will also meet the requirements you never tested is “a dangerous assumption” (2. Raab, 2020). The job description screens out wrong hires. It leaves the diligence unfinished. Raab’s answer is to keep defining requirements and, once you’re down to 1 or 2 finalists, run a proof of concept: install a trial and watch it run your job (2. Raab, 2020).
And some tools should be role hires. The system of record that your revenue reporting runs on holds a permanent seat, and so does the platform everything else plugs into. The mistake is writing every contract as if tenure were the default, when most of the stack was hired for work that ends.
Remake the decision at renewal
Jobs end. The campaign architecture changes, the team that owned the outcome reorganizes, the migration completes. The subscription keeps renewing as if the hire were permanent, which is how a stack fills up with tools whose jobs finished 2 years ago.
Renewal is the natural re-hiring moment. Ask 3 questions per tool: what job is it doing this year, who owns that job, and what signal shows the work happening. A tool with 3 answers earns its renewal. A tool with no answers is a candidate to cancel.
Write the job description before the demo, and reread it before every renewal. If you can’t write the job in 1 sentence, hold the purchase until you can.
Frequently Asked Questions
What does jobs to be done mean in martech?
How do I write a job description for a martech tool?
Isn't buying martech by category faster?
Do some martech tools deserve a permanent role?
What's the difference between a use case and a job?
References
- Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Know Your Customers’ “Jobs to Be Done.” Harvard Business Review. https://hbr.org/2016/09/know-your-customers-jobs-to-be-done (Evergreen: the foundational jobs-to-be-done article, and no newer edition replaces it.)
- Raab, D. M. (2020). Don’t Misuse Proof of Concept in System Selection. Customer Experience Matrix. https://customerexperiencematrix.blogspot.com/2020/07/dont-misuse-proof-of-concept-in-system.html (Evergreen: a method argument about use cases and proof of concept in software selection, which hasn’t dated.)
- Hightouch. (2024). Hightouch + Calendly. Hightouch. https://hightouch.com/customers/calendly (Vendor case study; results are self-reported.)
