Problem Framing and Schrödinger’s CRM

“One of my biggest frustrations,” the CEO told me, “is that because we don’t have a CRM system, we lack the data we need to be truly customer-centric.”

It sounded like a clear statement of the problem. It was certainly clear enough to suggest a solution: acquire and implement a CRM system.

A few days later, however, the head of IT confided in me that the connections and data flows from the CRM system to the marketing team were not quite as dynamic as they should be.

You can see why I was confused.

Did they have a CRM system or didn’t they?

The CRM system that both existed and didn’t

The answer turned out to be a bit of both.

The organisation had a CRM system, but it was used only by the operations team responsible for customer servicing. A troubled implementation, followed by budget cuts, meant that it had never been rolled out to the substantial sales team.

From the operations team’s perspective, the organisation had a CRM. It contained customer records and supported day-to-day servicing.

From the sales team’s perspective, it did not. Salespeople had no meaningful access to the system and did not use it to manage prospects or opportunities.

From the CEO’s perspective, the CRM might as well not have existed. It could not provide the customer and prospect information needed to support the organisation’s ambitions.

It was Schrödinger’s CRM: present or absent depending on who opened the box.

That contradiction exposed something more interesting than a failed technology implementation. It showed how the way we express a problem shapes the way we try to solve it.

“We don’t have a CRM” is only one level of the problem

This is not really an article about CRM systems. The CRM is simply a useful example of a common strategic error: describing the absence of a proposed solution as though it were the problem itself.

“We don’t have a CRM” sounds like a problem statement. But it describes the absence of a particular system.

Embedded within it is an assumption that a CRM is the required solution.

That assumption may be reasonable. It may even prove correct. But beginning there narrows the investigation before we properly understand what the business is unable to do.

The CEO’s underlying problem might have been expressed more precisely:

We cannot reliably identify which customer enquiries come from our priority customer segments, so we cannot target our marketing towards them effectively.

That statement operates at a different level.

It identifies a missing business capability: the ability to classify and analyse customer enquiries. It connects that capability to a strategic priority: reaching the customer segments the organisation most wants to serve. And it describes the consequence: marketing resources cannot be targeted as effectively as they could be.

This version gives us far more to investigate.

Do we know which customer segments should take priority? Do we collect the information needed to assign enquiries to those segments? Is that information accurate? At what point in the customer journey is it captured? Can marketing access it? Can the organisation connect marketing activity to subsequent sales and customer outcomes?

A CRM system may form part of the eventual answer. But the clearer problem statement prevents us from mistaking the purchase or rollout of software for the achievement of a business outcome.

Problems exist at several levels

Leadership teams often express problems through the most visible missing component:

• We don’t have a CRM.
• We need a new reporting system.
• We don’t have a data warehouse.
• We need an AI strategy.
• We need more salespeople.
• We need a new organisational structure.

These statements are useful starting points, but they sit close to the proposed solution. They tell us what someone believes is missing without fully explaining what the organisation needs to do, why it cannot do it today or what consequence follows.

The CRM example matters because it makes this distinction easy to see, not because CRM is unique. The same confusion can arise whenever a familiar solution, such as a system, a new team, a recruitment plan or a restructuring, is allowed to stand in for the underlying business problem.

A problem can usually be described at several levels.

In this case, the levels might look something like this:

1. System level: We don’t have a CRM available to the sales team.
2. Data level: We do not consistently capture information about prospects and customer enquiries.
3. Capability level: We cannot identify and compare enquiries from our priority customer segments.
4. Activity level: We cannot target marketing activity towards those segments effectively.
5. Outcome level: We may be spending time and money attracting the wrong prospects while missing better opportunities.

Each statement may be true. But each one opens a different conversation.

The system-level statement encourages a technology project. The capability and outcome statements invite a broader investigation of strategy, data, processes, behaviours and technology.

The more precisely you can connect the immediate difficulty to the desired business outcome, the better your chances of designing an appropriate response.

A workaround can conceal the real problem

I asked the head of sales how his team managed without access to the CRM.

He was not overly concerned. By his own admission, he was a little old-fashioned. I would not call him a Luddite, but he was not someone who naturally embraced new technology simply because it was available.

His team had developed a fairly complicated collection of spreadsheets and manual consolidation processes. Individual salespeople maintained their own records, which were periodically combined for reporting and forecasting.

They knew the arrangement was not ideal, but it worked.

Customers were contacted. Opportunities were pursued. Reports were produced. From within sales, there was no immediate crisis demanding attention.

The workaround solved the problem as the sales team experienced it: “How do we keep track of our opportunities?”

It did much less to solve the organisation-wide problem: “How do we build and use a coherent understanding of prospects and customers throughout their relationship with us?”

The spreadsheets allowed salespeople to perform their immediate tasks. They did not provide marketing with consistent data. They did not create a shared view of the customer. They did not enable leaders to connect marketing activity, sales conversations and customer outcomes.

The apparent success of the workaround therefore depended on where you stood and which problem you were trying to solve.

Why we did not begin with a CRM rollout

Extending the CRM to the sales team was an obvious option. We did not jump straight to it.

We first stepped back and worked through the organisation’s strategy.

Which markets and customer segments mattered most? What did customer-centricity mean in practical terms? Which decisions did leaders want to make? What information would support those decisions? Where and when could that information be captured? Which teams needed to use it?

This changed the character of the technology discussion.

Instead of asking only how to give the sales team access to the CRM, we could ask:

• What must the organisation know about each enquiry, prospect and customer?
• Which information is strategically valuable rather than merely interesting?
• Who should capture it, and at what stage?
• Which decisions and activities should it inform?
• How should information move between marketing, sales and operations?
• What would encourage people to use the new process consistently?
• Which capabilities should be implemented first?

By the time we returned to the CRM, we had a clearer basis for designing, prioritising and implementing the solution.

The technology could now support the strategy rather than define it.

Better problem framing produces more options

Poorly framed problems close down options prematurely.

If the problem is “we don’t have a CRM”, the likely answer is to buy or extend a CRM. Success may then be measured through implementation milestones: licences purchased, users onboarded, records migrated and integrations completed.

Those measures tell you whether the project delivered a system. They do not tell you whether the organisation can now identify priority enquiries, target its marketing more effectively or make better customer decisions.

Expressing the problem as a missing capability produces a wider and more useful set of options.

Perhaps the organisation needs clearer customer-segmentation criteria. Perhaps staff do not collect the right information when an enquiry arrives. Perhaps the data exists but cannot flow between systems. Perhaps salespeople see data entry as administrative work that provides them with no benefit. Perhaps marketing and sales use different definitions of a qualified prospect.

A CRM rollout might address some of these issues. It will not resolve them merely by existing.

The same principle applies beyond CRM. A new reporting system may not solve unclear decision-making. A data warehouse may not solve inconsistent data definitions. More salespeople may not solve an unclear value proposition or weak lead qualification. A new structure may not solve a lack of agreement about priorities, accountabilities or ways of working.

In each case, the proposed solution may eventually be necessary. The point is to avoid treating it as the problem before the organisation has established what outcome is impaired and why.

Clearer problem framing also produces better measures of success. Instead of asking whether the CRM has been deployed, leaders can ask whether the proportion of enquiries assigned to a priority segment has increased, whether marketing can use that information and whether campaigns are generating more of the opportunities the organisation wants.

The measures follow the business problem rather than the project plan.

Ask the question that feels too basic

One advantage of entering an organisation as an external consultant is that you are allowed to ask questions that insiders may feel they ought to know the answers to.

“Do you have a CRM?” sounded almost absurdly basic. Yet the leadership team did not share a common answer.

The useful follow-up was even more basic:

When you say you do not have a CRM, what is it that the organisation cannot do?

That question moves the conversation from objects to capabilities and from capabilities to outcomes.

With a different proposed solution, the wording changes but the test remains the same. When someone says the organisation needs a system, a team, a structure or a strategy, ask what the organisation is unable to do without it. Then ask why that matters.

Keep going until the relationship between the immediate problem and the strategic outcome becomes clear.

This does not make the original statement wrong. “We don’t have a CRM” captured the CEO’s frustration in a concise and understandable way. It just did not provide enough precision to design the response.

Open the box before choosing the solution

The lesson from Schrödinger’s CRM is not confined to CRM systems.

The CRM is one example of how easily a solution-shaped statement can be confused with the problem it is intended to solve. Leadership teams often agree on a sentence while holding quite different understandings of what it means. They may also accept a solution-shaped description of a problem because it is familiar, tangible and easy to communicate.

Good strategy requires more patience.

Before deciding what to build, buy, restructure or recruit, describe the business activity you cannot perform, the reason you cannot perform it and the outcome being impaired.

In this case, the progression was:

We don’t have a CRM.

Then:

We don’t have complete and accessible information about prospects and customers.

And finally:

We cannot identify which enquiries come from our priority customer segments, so we cannot target our marketing towards them effectively.

That final statement gives a leadership team something it can investigate, test and ultimately solve.

What next?

If your organisation is struggling to move from a proposed solution to a clearly framed strategic problem, book a conversation to discuss your needs.

StratNav provides the structure and scaffolding to help you get that framing right. It helps you distinguish between descriptions of your operating model, strategic goals, the choices, decisions and alternatives you need to consider, and the solutions you ultimately choose. That separation makes it easier to test assumptions, explore options and ensure that a solution such as a CRM supports the outcome you are trying to achieve rather than becoming the strategy itself.

Try StratNav to give your team a clearer way to frame problems, make strategic choices and connect solutions to the outcomes that matter.