PMM Means Business

Data Readiness Is Missing From Your ICP

Jul 9, 2026·12 min·By Maureen West

For many years now, product marketers have been keenly aware of the buying process problem. Sometimes it felt like a Sisyphean task. Every time product marketers seemed to gain traction on some aspect of the job, a new wrinkle appears. This time, it's AI.

How We Got Here

We know buyers have been doing desktop research for many years already — and software vendors responded with mountains of content to persuade. All with the good intention of helping buyers come to a decision — to buy their solution — more quickly. Over the years, the buying committee expanded greatly with more and different types of buyers included in the process and the decision, which is bonkers when the thrust of SaaS was to avoid large committees who needed to make expenditure decisions. Once again, vendors responded with endless slides and facts about "personas." Yet here we are, with the buying committee ratcheting up the complexity even though AI is now playing the lead research role.

Where We're Going

What's been the effect of AI on the buying process? Well, besides that it plays the role of lead researcher delivering information more quickly, not much else at this point. There's data showing how the buying committee is expanding again and while research times are compressed, the buying cycle and decision are actually getting longer. And worse, AI seems to be prompting vendors to create even more useful-adjacent content. Worse still, spend is being questioned (again!): Gartner's 2026 CMO Spend Survey shows it fell to 19.4% of marketing budgets, down from 26.6% in 2021. Every dollar is under scrutiny, and buyers know it.

As a product marketer, one of your tasks is to create assets that help educate the buyer. But in the outward direction — not by explaining the tech more clearly. Don't get me wrong here, the narrative about the solution is critical. It's the thing that will help your buyers absolutely develop a feeling about your company. This new content doesn't seem to be helping in any meaningful way though, since 75% of B2B buyers say they're taking longer to make purchase decisions than they did two years ago, according to Forrester.

And even after all that extra research, most of them still regret what they bought. Gartner found 60% of software buyers report regret after a purchase, and when they broke down the product-related causes, the top two weren't features or fit — they were higher-than-expected total cost of ownership and slow or complex implementations. A quarter of the buyers who felt that regret canceled their contracts outright. A third switched vendors. All that time spent researching, and the thing buyers still get wrong is the same thing every time: what it actually takes to run this once it's theirs.

The Turnkey Myth

We were told SaaS is turnkey. And it is, once you add your data in a precise way and you have a person caring for its many integrations, workflows, and reports. We're pretending software is an easy button that just works out of the box. By focusing on the aspiration of the tool rather than the foundation, we ignore the reality that software lives in an ecosystem. This myth hides the technical and staffing requirements behind a veil of ease, leading straight to the friction we see and feel during implementation.

Buyers are completing somewhere between 70% and 80% of their evaluation before a vendor knows the deal exists, per Gartner and Forrester data. AI has accelerated and anonymized the research phase. The vendor response was to flood the market with content — more case studies, more ROI calculators, more comparison guides, more, more, more about the user using the product — but none of this accounts for the environment in which the product lives. For years, vendors have tried to leave the technical details out of the sales conversation — and I can see why. If the right, or wrong, person is in the room, the entire conversation can be hijacked. It's a tightrope conversation that vendors must prepare for in the age of AI. And especially if your product includes AI. We're at the point in time where vendors need to discuss data requirements before the deal is signed — because that is what buyers really want to know about as SaaS has become more complex, some might even say bloated.

Buyers will also ask questions like how many people they'll need to run this tool, as AI is great at compressing the time to do things, usually — but it has knock-on effects we are still trying to sort out — like how many people it takes to successfully run a team or tool, what that team will do versus the AI, and how we know if we're getting value out of the AI. These questions will be asked about soon. So how should product marketers be thinking about this new wrinkle in the buying process?

The ICP Problem

I'd start with the ideal customer profile, because this is where the old model breaks.

Earlier in the lifespan of SaaS software, the hallmarks of an ICP were company size (either people or revenue), team size, and tech stack. These were answering questions like: do they have the budget to buy the solution, and do they have the capacity to run it. Those signals have been turned on their head with AI. Smaller teams can now run sophisticated software with the assistance of their own agents, or agents built into the tool. These smaller teams might also have the budget to keep buying sophisticated tools. But those signals are becoming useless in the conversation, because at the heart of every deal, you're trying to fit a tool built entirely outside an organization into an organization that's already in the throes of its own business.

Which brings me to data. The thing tech people have in spades is data. How many users are logging in, how long they were in the tool, which features they used, how long the sales cycle is, how many pieces of content were sent (less confident about engagement, but moving on). In short, tech companies have data on nearly every aspect of their internal business. Anything you can measure gets a metric.

What Implementation Actually Costs

Let's look at implementations — the next activity that brings vendor and buyer together. And it's by far one of the most tenuous parts of a new software relationship. Here, the favorite SaaS metrics are time to value, product adoption (both the number of features used and the number of seat licenses), and of course renewal/churn. These metrics are trying to measure something completely outside the control of the company. The success of these metrics lies with the customer and their internal business situation. If you have a customer with processes, people, and clean data, the implementation will go very well. If you are missing processes but have people and data, the tool could be the stand-in for the process — not advisable, but doable. Then there's the situation of not having the processes, people, or clean data required by the vendor system. The newest scenario is having tools and data, but no people, because AI was supposed to handle that. These are the kinds of real factors that affect your expansion and retention numbers. Shouldn't questions related to readiness and capacity be asked well before implementation?

The value derived from software is the ability to use it without vendor intervention. Getting clear about what a customer's internal workings are like should be part of the discussion. A small team with little experience means your CSM spends more time with that customer and ignoring others. A customer with a large contract, or brand, ties up your product team with feature requests, and of course those get follow up because money. Both of these scenarios could have been addressed during the sales cycle by explicitly discussing the requirements of implementation. Some customers genuinely don't care how many other customers you have — they've paid you and they want answers. They aren't wrong, but these are scenarios that could have been avoided, or at least carefully considered.

Redefining the ICP

Back to the task at hand — redefining the ICP. For the modern software company, finding the right customer is more critical with spending undergoing continuing scrutiny.

The current definition of ICP includes characteristics about the company, persona profiles related to the buyer, persona profiles related to the user, and the ideal tech stack. If this were truly all that was needed to understand whether a prospect is a fit, how do we account for the churn happening across tech right now? Gartner and Forrester have put CRM failure rates between 50% and 70% for two decades running, and the reasons cited are rarely about the software itself. Gartner's own Marketing Technology Survey found martech stack utilization fell from 58% in 2020 to 33% in 2023, and named customer data challenges — collecting it, unifying it across systems — as a leading cause. And how do we account for reviews that explicitly cite implementation as the reason for churn, when none of that shows up in a standard ICP?

I call this a translation problem — an error in translation between the demo and the readiness of the prospect. They might have the tech stack, the right players on the committee, and even the use case, but if your solution requires a person to run it, a months-long data-heavy implementation, and a rigid data architecture, without explicitly asking about their readiness to implement, not buy, you really don't know anything about what either side is getting into.

The new ICP should include data expectations. What data do they need on hand to be successful? How is that data used in workflows — is that workflow accessible for all versions of the software, or only for top-tier spenders? How clean does the data need to be — can it have gaps, and what kind of gaps are tolerated by the system before performance erodes? These questions are necessary to ask in the age of AI because AI cannot clean your data for you, especially when it's missing.

You might think I've lost my marbles bringing up a potential show-stopper before you close, but a customer who isn't ready will cost you far more than their contract value — in CSM time, support tickets, custom feature requests, the deals you lose because their implementation became a reference story you couldn't use, and the word that spreads when they tell their peers about it.

Qualifying for Readiness, Not Just Budget

Readiness isn't something obvious or available to assess through content engagement. And it's something I think most vendors take for granted. Depending on the stage and growth rate of a vendor, they'll work with any customer with a budget. The sales process should be considered a way for the vendor to assess the prospect as well. It benefits both sides to bring this level of rigor to the sales cycle.

Understanding readiness isn't hard, but it could mean delaying a deal until the time is right. To assess readiness, it requires sellers to ask good questions and prospects to provide meaningful answers. Worst case scenario: if a prospect gets defensive about reasonable readiness questions, that's useful information. They may not be the partner you want. What you're looking for are prospects who have a realistic understanding of the health of all the data that will connect to the new solution, not just the tool being installed or replaced. Asking about data flow, governance, and source of truth are the right level of conversation to have before deal close. Sharing how data is prioritized, and why, helps the prospect understand if this is something they want to take on, or if they can even meet the bar.

Of course, I don't recommend these as the first questions, but you can strategically ask them throughout the sales cycle. I'd start with asking about implementation priority right out of the gate, since this gives you an idea of how quickly the sales cycle could move and how ready the prospect will be when implementation starts. If your prospect indicates high or highest priority, then you can begin asking questions about data health and readiness during the demo.

Here's how I'd think about rewiring the qualification process to focus on prioritization:

At discovery:

  • Is this an agreed-upon problem throughout the organization?
  • Do you have partners internally to make implementation and adoption a success?
  • Who is going to make the decision?
  • What is the decision criteria?

At demo:

  • How would you describe the health of your data and tech stack?
  • How are you thinking about integrations?
  • What have you done to prepare for implementation?
  • Do you have a dedicated resource for the entire implementation?

Post-demo:

  • Did the demo answer your workflow questions?
  • What process changes would you need to make before go-live?
  • What does it take to change processes in your organization/team?

Demos are typically the thing everyone points to as the turning point of the deal. I'd say: maybe. If the conversation is about budget and champion only, no. If it includes answers related to readiness and data quality, yes.

I am not suggesting this change to scare off prospects or add to the already complicated process. It's to create the conditions for mutual success before signing a contract.

Vendors have to be willing to speak about what their products require to be successful — not give away the architecture, but be clear about data structure, prerequisites, and what a realistic implementation looks like for a company at the prospect's stage. Buyers who understand what they're getting into before they sign are better partners, realize value more quickly, and are more likely to renew.

The buying conversation and the implementation conversation have been two separate things for too long. Vendors who start talking about true cost of ownership — the data architecture and staffing needs — are laying the foundation for a long relationship built on mutual understanding.

Data readiness deserves to be the first input into a buying decision, not an afterthought discovered during implementation. That means two things: understanding your own organization's readiness, and understanding what the vendor's system actually requires, based on what's publicly available about how it works. That pairing, buyer readiness against vendor requirements, is what Delphi is built to help with, before a contract is signed instead of after.