Part II: Strategy & Planning

Chapter 3: Internal Demand Analysis

Ali Süleyman Topuz

“The difference between a useful AI system and an impressive one is whether someone in your organization has a real problem that it actually solves.”

The Problem with Building What Is Easy

Every organization has a version of this conversation. A team becomes excited about AI. Someone suggests a use case often the use case they have seen demonstrated at a conference, or the one that received the most enthusiasm in a brainstorming session, or the one that the most technically vocal engineer has already prototyped. The idea gains momentum. A sprint is allocated. The work begins. And several months later, when the feature has shipped and the usage data has come in, the numbers are underwhelming. Customers use it occasionally. Internal teams find it marginally helpful. Nobody can quite articulate what problem it was solving.

This is the failure mode of AI investment without demand analysis. The team was not lazy. The feature was not technically poor. The problem was that the use case was chosen based on availability it was the idea that was most present in the room, most technically accessible, most compatible with the existing architecture rather than based on a systematic understanding of where AI could genuinely deliver value. Availability bias is the most common driver of poorly chosen AI use cases, and it is especially dangerous in AI because the technology is novel enough that people confuse “this is technically interesting” with “this is organizationally valuable.”

Internal demand analysis is the antidote to availability bias. It is the structured process of mapping, from the inside out, where your organization actually needs AI not where it would be easy to add AI, not where it looks impressive to investors, but where a real problem exists that AI is well-suited to address. Done well, it produces a prioritized list of opportunities grounded in organizational need, feasible given current capability, and significant enough to justify the investment required to execute them.

This chapter covers how to run that process: how to surface genuine demand, how to distinguish strong opportunities from attractive-sounding ones, how to score and rank what you find, and how to translate your findings into the candidate use cases that will anchor your roadmap.

What Internal Demand Analysis Is and Is Not

Internal demand analysis is not a brainstorming session. It is not a hackathon. It is not an invitation for engineers to propose the AI features they find most interesting. All of these activities have value, but they are generative rather than diagnostic. They produce ideas. Internal demand analysis produces evidence.

The distinction matters because ideas are abundant and evidence is scarce. Every technology team can generate more AI feature ideas than it can build in two years. The constraint is not ideation it is prioritization. And good prioritization requires knowing, with some confidence, which problems are most costly, which processes are most broken, and which users are most underserved. That knowledge does not come from brainstorming. It comes from looking carefully at what is actually happening in your organization and asking, systematically, where AI could change it.

Internal demand analysis is also distinct from customer demand analysis, which is covered in the next chapter. Internal demand focuses on the operational processes, team workflows, and organizational functions that sit behind your product the work your team does to build, deliver, and support it, and the internal systems that support that work. Customer demand focuses on what your customers experience directly. Both are necessary for a complete AI strategy. This chapter addresses the internal side because it is, in practice, where most organizations have the lowest-hanging fruit and the clearest data.

The output of internal demand analysis is a ranked list of candidate use cases specific, scoped descriptions of where AI could create value accompanied by evidence of the demand that justifies them and an initial assessment of what it would take to pursue each one. This output becomes the primary input to your roadmap, covered in Chapter 6.

Three Types of Internal Demand

Not all internal AI demand looks the same. Before running the discovery process, it helps to understand the three distinct categories that internal demand tends to fall into, because each category implies different types of AI solutions and different success metrics.

Efficiency demand is the most immediately visible type. It arises when a team is spending significant time on work that is repetitive, low-judgment, and high-volume work that produces value but that takes more human time than the value warrants. Answering the same category of support question repeatedly. Manually reformatting data between systems. Writing the same type of document from scratch when 80% of the content follows a consistent pattern. Efficiency demand is characterized by high frequency, clear inputs and outputs, and a relatively unambiguous definition of what “good” looks like. AI is well suited to address efficiency demand, and doing so produces measurable returns: time saved per task, volume handled per team member, cost per transaction.

Quality demand is less visible and more important. It arises when a team is doing work that matters significantly to business outcomes, but the quality of that work is inconsistent either because it depends on individual judgment that varies between people, or because the team does not have time to do it well consistently given volume constraints. Onboarding execution that varies between CS reps. Sales discovery conversations where some reps cover the key qualification questions and others do not. Technical documentation written by engineers who are excellent at engineering but inconsistent at clear writing. Quality demand is characterized by meaningful variation in outcomes, identifiable best-practice patterns, and a measurable cost of low quality support escalations, churn, rework. AI is well suited to support quality demand by providing consistent structure, real-time guidance, or automated review. Not replacing judgment, but making good judgment more consistent and accessible.

Capability demand is the most strategically important and the least immediately obvious. It arises when there is something the organization genuinely cannot do today not because the team is inefficient or inconsistent, but because the capability simply does not exist at the required scale or speed. Processing the full history of customer interactions to identify patterns that predict churn. Generating personalized recommendations for every customer at the moment they need them. Monitoring thousands of configurations in real time for anomalies that require human review. Capability demand describes things that would be transformationally valuable but that are not currently possible without AI. These opportunities often require more infrastructure investment and longer lead times, but they produce the most durable competitive advantages.

A well-structured demand analysis will surface all three types. The typical finding is that efficiency demand is abundant, quality demand is significant but underestimated, and capability demand is limited but highly valuable. The roadmap should address all three in proportions appropriate to the organization’s maturity and risk tolerance.

Running the Demand Discovery Process

The demand discovery process has two components: structured stakeholder conversations and quantitative signal analysis. Neither is sufficient on its own. Stakeholder conversations surface the qualitative texture of where demand exists the language people use to describe their pain, the specific scenarios that cause frustration, the aspirations that people hold for what their work could look like. Quantitative signal analysis surfaces the scale and cost of those problems, providing the evidence needed to prioritize between competing demands.

Structured Stakeholder Conversations

The right participants for demand discovery are the people who manage the work, not necessarily the people who do it. Department heads, team leads, and senior individual contributors have the dual perspective needed: they understand both what the work requires and what it costs when it goes wrong. Run thirty- to forty-five-minute conversations with the leads of each major function: engineering, product, customer success, sales, and operations at minimum.

The conversation should not begin with AI. It should begin with pain. The following five questions, asked in order, reliably surface the demand that matters.

“Walk me through a week in your team’s work. What takes the most time?” This question surfaces volume the high-frequency work that dominates the team’s calendar and that, almost by definition, represents the most significant efficiency demand. Let the answer be specific and operational, not strategic.

“Where does quality vary most between your best and worst performers?” This question surfaces quality demand. The gap between your best and worst performers in any function is the gap that AI can help close by encoding the practices of the best performers and making them consistently accessible to everyone on the team.

“What do you wish you could do that you currently cannot, because you don’t have the time or the information?” This question surfaces capability demand. The answer here is often the most strategically important part of the conversation, and it frequently requires prompting people have learned to suppress aspirations that feel unrealistic given current constraints. Give the question space. The first answer is rarely the most interesting one.

“What are the most common reasons work gets delayed, escalated, or done over?” This question surfaces friction points the handoffs that go wrong, the exceptions that break the process, the information gaps that force rework. These are often excellent AI opportunities because they represent predictable failure modes that a well-designed system can catch or prevent.

“If you could make one thing about your team’s work dramatically better in the next twelve months, what would it be?” This question surfaces priority what the person running the function considers most important, independent of what AI can or cannot do. The answers ground your subsequent prioritization in organizational reality rather than technical enthusiasm.

Take detailed notes. Record specific examples and scenarios. The specificity of the answer “our CS team spends about two hours per day answering questions about how to configure the scheduling module” is more actionable than a general statement “our CS team spends a lot of time on repetitive questions.”

Quantitative Signal Analysis

Stakeholder conversations tell you where people feel pain. Quantitative analysis tells you how much that pain costs. For each major pain point surfaced in the conversations, conduct a basic quantification.

How many times per week does this situation occur? How much time does it take each time? What is the approximate loaded cost of that time? What is the measurable business cost when it goes wrong in churn, in delayed revenue, in customer satisfaction scores, in rework hours?

You do not need precision here. An order-of-magnitude estimate is sufficient for prioritization purposes. A process that takes two hours per week per CS rep across twelve reps represents twenty-four hours per week, or roughly one full-time equivalent per year. At a loaded cost of $80,000 per year for a CS rep, that is a meaningful cost even before accounting for the opportunity cost of what those hours could otherwise accomplish.

For some pain points, the quantitative signal is already available in your operational data. Support ticket volume by category. Time-to-resolution by ticket type. Onboarding completion rates by step. Churn rates correlated with specific journey events. Where this data exists and is accessible, use it it is more objective than self-reported estimates and often surfaces demand that stakeholders have normalized and stopped noticing.

Mapping Pain Points to AI Opportunities

With discovery complete, the next step is translation: converting the raw material of pain points and friction signals into specific AI opportunities. Not every pain point maps cleanly to an AI solution, and understanding the mapping requires discipline.

The mapping exercise works best with a simple three-column structure. Column one describes the pain point in specific, operational terms. Column two describes the AI capability that could address it. Column three assesses the fit whether the pain point is a strong, moderate, or weak candidate for AI.

Strong candidates share a common profile: the work is high-volume and repetitive, the inputs and outputs are well-defined, a correct output can be reasonably determined and measured, the data required to run the AI system is available or achievable, and the cost of AI failure is contained. Support ticket classification is a classic strong candidate. Route planning optimization is another. First-draft generation for templated documents is another. When a pain point matches this profile, AI is well suited and the investment is relatively low-risk.

Moderate candidates are situations where AI can clearly help but where the complexity is higher. Outputs are less standardized. Data is partially available but requires preparation. Quality evaluation requires ongoing human judgment. An onboarding assistance tool is a moderate candidate: AI can handle common questions and guide standard configuration steps, but the complexity of edge cases means human escalation paths are essential and quality monitoring requires sustained attention. Moderate candidates are worth pursuing but require more careful scoping, stronger evaluation frameworks, and more explicit human-in-the-loop design.

Weak candidates are situations where AI is being proposed as a solution to a problem that is fundamentally organizational rather than technical. A process where the problem is that nobody owns it. A workflow where the real issue is unclear accountability rather than insufficient automation. A quality problem that stems from inadequate training rather than inconsistent application of known practices. AI applied to these situations does not solve the underlying problem it makes the problem operate faster. Weak candidates should be deferred until the underlying organizational issue is addressed.

One category deserves specific attention because it accounts for a meaningful fraction of AI proposals that underdeliver: the convenience feature. These are situations where AI would make something slightly easier but where the existing solution is already adequate and the AI investment is disproportionate to the marginal improvement. A natural-language search bar is appealing, but if existing search works reasonably well and users can find what they need, the improvement from AI-powered search may not justify the infrastructure investment. Convenience features are real improvements, but they are not transformation and they should be weighted accordingly in prioritization.

Scoring and Prioritizing Opportunities

The output of the mapping exercise is typically a list of fifteen to thirty candidate opportunities. The challenge is reducing this list to the five to ten that will anchor your roadmap, without losing the genuinely strong ones or elevating the wrong ones.

The scoring framework that works most reliably at this stage uses three dimensions: impact, feasibility, and data readiness. Each is scored from 1 to 5, and the composite score weighted according to your organization’s current priorities determines the initial ranking.

Impact (1–5) measures the business value of successfully addressing this opportunity. A score of 5 means the opportunity, if executed well, produces structural changes to cost, revenue, retention, or capability that compound over time. A score of 3 means the opportunity produces meaningful but bounded improvements. A score of 1 means the improvement is real but modest in scale. When scoring impact, use the quantitative estimates from the discovery process the cost of the problem, the revenue at risk, the churn correlated with the friction rather than intuitive judgment. Impact is the most important dimension and should be weighted most heavily.

Feasibility (1–5) measures how straightforward it would be to execute this opportunity given your current team capability and infrastructure. A score of 5 means the technical approach is well understood, the team has done something similar, and the infrastructure is in place. A score of 3 means meaningful technical work is required but the approach is clear. A score of 1 means significant new capability or infrastructure investment is required before work can begin. Feasibility is not a measure of whether something is worth doing a high-impact, low-feasibility opportunity is worth the investment. It is a measure of how quickly the opportunity can deliver value and how much risk it carries during execution.

Data readiness (1–5) measures whether the data required to build and run the AI system is available in usable form. Use the use-case-level data inventory from Chapter 2 as your primary input here. A score of 5 means the data is clean, accessible, and sufficient. A score of 3 means the data exists but requires meaningful preparation. A score of 1 means significant data work must precede the AI work.

Score each opportunity independently, then calculate a weighted composite. A suggested weighting for most B2B SaaS organizations at the beginning of transformation: Impact × 0.5 + Feasibility × 0.3 + Data Readiness × 0.2. Adjust the weights based on your constraints if team capability is the primary constraint, weight feasibility more heavily. If you are under near-term pressure to demonstrate results, weight both feasibility and data readiness more heavily relative to impact.

The ranked list is your initial priority order. Before finalizing it, apply one additional filter: dependency sequencing. Some high-scoring opportunities depend on infrastructure, data pipelines, or team capability that will only be available after other work is complete. Identify these dependencies explicitly and ensure the eventual roadmap respects them. A high-scoring opportunity that requires a data pipeline not yet built should be sequenced after the pipeline work, even if it scores higher than the pipeline project itself.

The Build vs. Enable Question

For each high-priority opportunity, before committing to engineering, ask a question that is frequently skipped: should we build this, or should we enable it?

Building means your engineering team designs and implements an AI system using AI APIs, your own data, and your own infrastructure. It produces an asset you own, can customize deeply, and can improve over time with proprietary data. It also requires ongoing maintenance, operational responsibility, and engineering investment that does not end when the initial version ships.

Enabling means deploying a third-party AI tool that addresses the need without custom engineering work. It produces faster initial value, lower engineering overhead, and the ability to evaluate fit before committing to a custom solution. It also produces dependency on the vendor’s roadmap, constraints on customization, and potentially higher long-run costs as usage scales.

The build vs. enable decision for internal use cases follows a different logic than the same decision for customer-facing features. For internal operational improvements, the threshold for enabling rather than building should be meaningfully lower. Internal AI tools do not differentiate your product. They improve your operations. A customer success team using a third-party AI assistant to draft support responses is getting the same operational benefit as one using a custom-built assistant at a fraction of the engineering investment. Reserve custom engineering for the opportunities that are genuinely differentiated: use cases that involve your proprietary data, your specific operational context, or your customers’ direct experience.

The three questions to ask for each opportunity: Does this use case require deep integration with our proprietary data or processes, in ways that an off-the-shelf tool cannot accommodate? Would a generic AI tool be meaningfully worse than a custom one for this specific use case? Is the operational workflow complex enough that a configurable third-party tool would not adequately support it? If the answer to all three is no, the right starting point is likely to enable rather than build. Many organizations discover that enabling an off-the-shelf tool for twelve months, then building a custom solution informed by what they learned, produces better results than building from scratch without the operational context that real usage generates.

Biases and Blind Spots in Demand Discovery

The demand discovery process surfaces real problems, but it is not immune to the organizational dynamics that shape how people describe their work. Understanding the most common sources of bias helps you interpret what you find more accurately.

The recency bias. People describe problems they have encountered recently more vividly than problems that occur regularly but less dramatically. A CS rep who handled a frustrating escalation last week will describe that category of problem in more detail than the quiet inefficiency that consumes two hours of every day. When synthesizing findings from multiple conversations, weight frequency and cost over vividness. The anecdotes that feel most compelling in the room are not necessarily the problems that cost the most.

The aspiration-disguised-as-demand problem. When asked “what do you wish you could do?”, some leaders describe genuine capability demand things that would genuinely transform what their team can do. Others describe aspirations that reflect their vision for the role rather than a real operational gap. The test for genuine capability demand is specificity: can the person describe exactly which decisions would be made differently, or which customers would be served better, if this capability existed? A vague answer “we’d be able to be more proactive” is likely aspiration. A specific answer “we’d be able to reach out to customers showing early churn signals before they decide to leave, rather than after” is genuine demand.

The “AI won’t help here” blind spot. Some of the most experienced team members will discount their own pain points on the grounds that “AI can’t really do this.” This judgment is often based on a mental model of AI that predates current LLM capabilities. When a department head says “AI couldn’t handle our support tickets because they’re too complex,” the right response is curiosity, not deference. Ask for three examples of the most complex ticket types. Often, you will find that 70% of the volume consists of patterns that are genuinely addressable by AI, and the “complex” cases are the tail that AI appropriately escalates.

The political filter. In most organizations, the demand discovery conversations will surface at least one significant pain point that reflects a political rather than technical reality a process that is broken because two departments have never resolved an ownership conflict, or a quality problem that traces back to a leader who resists process standardization. AI cannot solve political problems. Note these discoveries and handle them separately. Attempting to use AI to work around organizational dysfunction is a reliable way to produce an AI system that is technically functional and organizationally ineffective.

Awareness of these biases does not eliminate them, but it changes how you interpret what you hear. Weight the quantitative signals over the qualitative narratives when the two diverge. Ask follow-up questions that probe for specificity and evidence. And when multiple independent stakeholders describe the same problem, weight that convergence heavily it is the strongest signal that genuine, widely-felt demand exists.

From Opportunities to Candidate Use Cases

The final output of internal demand analysis is a structured list of candidate use cases. A candidate use case is more specific than an opportunity it names the problem, the proposed AI approach, the expected business impact, the data requirements, the feasibility assessment, and the open questions that need answering before work can begin.

A well-written candidate use case looks like this:

Support Ticket Classification and Routing. Currently, Priya’s CS team manually triages every inbound support ticket, categorizing it by type and routing it to the appropriate team member. This takes approximately ninety seconds per ticket and is performed by a senior CS rep who could otherwise be handling complex escalations. At current volumes of 140 tickets per week, this represents roughly 210 minutes of senior rep time per week, or approximately three-and-a-half hours. A classification model built on historical tickets could automate this categorization with high accuracy on common categories, routing unusual or ambiguous tickets to human review. Data readiness: high four years of categorized tickets are available in PostgreSQL. Feasibility: high this is a well-understood classification task with established implementation patterns. Impact: moderate time savings are real but bounded. Open questions: what is the acceptable misrouting error rate? How should the system handle the long tail of ambiguous or novel ticket types?

Candidate use cases written at this level of specificity serve two purposes. They are detailed enough to inform roadmap sequencing and initial resource estimation. And they are specific enough to expose the assumptions that need to be validated before engineering begins the open questions at the end of each description are the items that require investigation before the use case can be confidently scoped.

Aim for five to ten candidate use cases from the internal demand analysis. More than ten suggests that the scoring and prioritization work has not been applied rigorously enough. Fewer than five may indicate that the discovery conversations did not surface the full range of demand.

The candidate use case list is a living document, not a final decision. As you move into roadmap planning in Chapter 6, some use cases will be refined, merged, or deferred based on capacity constraints and sequencing considerations. Some open questions will reveal that a use case is more complex than the initial assessment suggested, and some will confirm that it is more straightforward. The discipline of writing use cases in this format is that those adjustments happen explicitly and with documentation, rather than silently and based on whoever is loudest in the room at a given planning meeting.

Key Takeaways

• Internal demand analysis is not brainstorming it is a structured diagnostic process that produces evidence of where AI can genuinely create organizational value.
• There are three types of internal demand: efficiency demand (repetitive, high-volume work), quality demand (inconsistent outcomes between people), and capability demand (things the organization cannot currently do at scale). A complete analysis surfaces all three.
• The discovery process combines structured stakeholder conversations built around five specific questions with quantitative signal analysis that translates pain into measurable cost.
• Not every pain point maps well to an AI opportunity. Strong candidates are high-volume, well-defined, and measurable. Weak candidates are situations where the underlying problem is organizational rather than technical, and AI would scale the symptom rather than address the cause.
• Scoring and prioritization should be explicit impact, feasibility, and data readiness, weighted appropriately for your context. Intuitive prioritization reliably elevates the interesting over the important.
• The build vs. enable question should be asked for every internal use case. For internal operational improvements, enabling off-the-shelf tools is often the right starting point. Reserve custom engineering for use cases that involve proprietary data or direct customer experience.
• The output of internal demand analysis is a structured list of candidate use cases: specific enough to inform roadmap sequencing, and specific enough to expose the assumptions that need validation before engineering begins.