Consultative Mindset (Context, Curiosity, Co-create)
A framework for technical sellers to engage customers as a consultant, not a pitch. Not a script, a mindset for how you show up in any technical conversation. Source: Microsoft MCAPS Academy, "Consultative Mindset in Action VILT, Technical Seller Participant Guide" and companion Field Guide.
When to use this skill
- Prepping for an upcoming customer or technical conversation, real or practice.
- Building a feasibility hypothesis before a meeting.
- Practicing with a fictional case (default: Northwind Logistics, see below) for role play training.
- Reflecting after a real conversation using the planner template.
- Any request mentioning consultative mindset, context curiosity co-create, feasibility hypothesis, technical seller framework, Northwind Logistics, or "help me build a hypothesis, options, or tradeoffs" for a customer.
The model at a glance
- Context: lead with a point of view. Collapse three inputs (what's changing, who's impacted, what's the impact) into one testable hypothesis.
- Curiosity: get to the problem that matters. Most conversations stop at the stated problem (step 2 to 3 of 5). Go deeper to the real need.
- Co-create: help the customer decide. Shift from solving for them to deciding with them. Five moves from reframe to agreed next steps.
Each has three altitudes: Emerging (functional, no point of view), Growing (has a point of view, tests it), Excelling (leads with insight, quantifies impact, de-risks the path). Aim for Excelling language, examples included in each section below.
1. Context: Build one hypothesis
What's changing: Hunt for the pressure forcing change. Separate the real trigger (the cue) from background noise (the backdrop). Test for "why now": what breaks or stalls in the next 1 to 2 quarters if they don't act. If the impact is minor, look for the more urgent pressure underneath it.
Who is impacted: Map 2 to 3 stakeholders to what each values. Hunt for where two stakeholders want opposite things, that conflict is often why decisions stall. Name the stakes: who gains or loses if nothing changes.
What's the impact: Ask "so what?" three ways: what is it costing today, what happens if nothing changes, where is time, money, or performance being lost right now. Get one directional number (ranges are fine, cite the basis). Keep it concrete, not abstract.
Collapse into one hypothesis: "In situations like this where [what's changing], [who is impacted] experience [what's the impact]."
Deliver this in the first 90 seconds of the conversation. It is a testable, humble statement the customer can confirm, correct, or expand. Not a conclusion, not a pitch.
Excelling sounds like: "I see you don't have a defined architecture in place and fragmented data is a challenge. How do your teams currently interact with multiple data sources?"
Suggested prompts: - "What technical or business pressures are forcing [customer], a [industry] company, to change right now: architecture strain, data fragmentation, integration complexity, cloud/hybrid shifts, scaling needs, or new security/governance constraints? For each, say why it's happening this quarter, not next year." - "From these notes on [customer] [paste news/account notes], which single change is most likely forcing a technical decision now, versus which are just background? Rank them and explain what makes the top one the real trigger." - "Apply a why now test to [change] at [customer]: what breaks or stalls in the next 1 to 2 quarters if they don't act? If the impact is minor, suggest the more urgent pressure underneath it." - "For a [industry] company scaling AI, who are the typical technical stakeholders: architects, security, data, platform owners, and what does each care about?" - "Where do security/architecture and delivery/business teams usually conflict when scaling AI across an environment?" - "For [customer]'s issue of [what's changing], answer three ways: (1) what is it costing today, (2) what happens if nothing changes, (3) where are time, money, or performance being lost right now? Keep it concrete." - "Give me a directional benchmark for what it costs [industry] firms to scale AI on fragmented, un-integrated data: duplicated effort, rework, delayed time-to-value, lost productivity. Ranges are fine, cite the basis."
2. Curiosity: Get to the problem that matters
Not about asking more questions, about where the question comes from. Five steps, most conversations stall at step 2 to 3: 1. Customer shares the problem as they see it. 2. You listen and probe. 3. You uncover what's really driving it. 4. You expose gaps, risks, or misalignment. 5. You land on the real need.
Question stems to go deeper: - "What's driving that?" - "So it sounds like X is the issue, can you walk me through it?" - "What other challenges are connected to this?" - "That makes sense. What's made this difficult so far?" - Challenge carefully: "Most teams struggle with X. How is that showing up for you?"
Name the real need back and test it: "So what I'm hearing is, for this to work, [X] must be true." Then check it against three tests: Important (is it costed?), Actionable (is it fixable?), Structural (does it persist even if you swap the person?).
Excelling sounds like: "It seems like real-time requirements are adding complexity here. Where am I wrong or missing something?"
Suggested prompts: - "A [role] at a [industry] company like [customer] told me: '[what the customer said]'. What could really be driving that technically: integration, data movement, architecture fit, security/governance, or adoption, and what symptom might I be mistaking for the real problem?" - "Give me three follow up questions about '[stated problem]': one that goes a level deeper into the architecture or data, one that tests a technical assumption the solution depends on, and one that surfaces what's missing or misaligned across teams." - "What's a short story, benchmark, or number about [industry] companies scaling AI where the real blocker was integration, data movement, or governance, that I could use to respectfully challenge how [customer] sees '[stated problem]'?"
3. Co-create: Help the customer decide
Role shifts from uncovering the problem to coaching the customer's decision. You are not presenting. The customer should leave with clearer thinking and ownership of what happens next.
Five moves: 1. Reframe the opportunity: turn the problem into a decision. "What are we deciding? What tension exists? What matters now?" 2. Introduce options: 2 to 3 realistic paths grounded in their reality. Create choice, not a single recommendation, no obvious winner. 3. Surface tradeoffs: what does each option require, what does it delay. Common tensions: speed vs depth, cost vs capability, scope vs feasibility. 4. Connect to business value: tie each path to outcomes, stakeholder priorities, and risk vs impact. 5. Agree to next steps: "What direction makes sense? Who owns it? When do you need to see results?" The next step must be decision-oriented and owned by the customer, not a task you quietly take on yourself.
Excelling sounds like: "Before we lock into an approach, what's most likely to create friction: integration, scale, adoption, or security?"
Suggested prompts: - "Help me reframe this from a technical problem into a clear feasibility/validation decision they're choosing between: 'The real question is whether to prove this with a prototype first, or commit to full rollout and validate as you scale.' Give me two framings." - "Draft two or three realistic, genuinely viable technical paths forward for [customer], grounded in their architecture and constraints, with no single obvious winner. Give each a short name, a one line description, and the architecture, aligned services, and visualization or prototype plan, including high value hands-on activities such as rapid prototyping, architectural whiteboarding, or technical workshops." - "For each option [paste], make the technical tradeoffs visible: what it gives, what it requires, what it delays, anchored in real tensions: speed vs depth, cost vs capability, scope vs feasibility." - "Tie each option to what matters to [customer]'s stakeholders, a specific requirement, the business outcome, and risk vs impact, so the tradeoff has a direction." - "Help me shape a validation step [customer] would own: a prototype, whiteboard, or technical workshop, plus a question that gets them to choose the direction, the success criteria, and who's involved and when."
Conversation planner (use for any real conversation)
Fill a fresh copy for each customer conversation:
This conversation: Customer and industry: _. Stakeholder(s) and role: . Date: _. My focus behavior: .
1. Context, build before the meeting - What's changing: name the pressure and why now, separate the cue from the backdrop. - Who is impacted: map 2 to 3 stakeholders to what they value, find the conflict. - What's the impact: ask so what, get a directional number or cost of inaction. - Your hypothesis: "In situations like this where [what's changing], [who is impacted] experience [what's the impact]."
2. Curiosity, get to the real need during the conversation - Questions to go deeper (see stems above). - What I heard: the problem as the customer framed it. - What's really going on: the gap, risk, or misalignment underneath it. - The real need: reframe what the opportunity actually is.
3. Co-create, shape the path forward - 2 to 3 realistic options the customer can take. - Tradeoffs: what does each require, what does it delay. - Business value it moves: outcomes, stakeholder priorities, risk vs impact. - Next steps: agreed, with an owner and a date.
Reflect, right after the conversation - What worked. - One thing I'll do differently next time.
Self-reflection prompts (use after any real or practiced conversation)
- Context: of the three inputs (what's changing, who's impacted, what it's costing), which do I consistently under-build before a first meeting?
- Curiosity: how often do I stop exploring at the first answer, or challenge the thinking behind it? When do I tend to settle, and what's underneath that: time pressure, the urge to solve, or discomfort sitting in the unknown?
- Co-create: in my conversations, who usually owns the next step, me, the customer, or someone else (partner, specialist, customer success, manager)? Do I spend more time helping customers decide, or helping them agree with my recommendation?
- Level up: reframe your next step so it is clearly decision-oriented. Hand the choice back to the customer, don't quietly own the task yourself.
Glossary
- Consultative Mindset: the overall approach, grounded in Context, driven by Curiosity, built through Co-create. Not a new methodology, how you show up in conversations you already have.
- Hypothesis: a testable, humble statement the customer can react to (confirm, correct, expand). Not a conclusion, not a pitch. Offered in the first 90 seconds.
- Point of view: an informed, directional perspective you walk in with, answering what the problem is, what's feasible, where the risk is, and what decision needs to be made.
- Real need: the underlying problem beneath the stated symptom, the solution-viability question, not just a business problem.
- Cost of inaction: what a problem is costing the business if nothing changes. Even a directional cost creates urgency and turns an interesting conversation into a qualified opportunity.
- Tradeoffs: the tensions inside any real decision, you can't optimize everything. Naming them forces a decision. Common pairs: speed vs depth, cost vs capability, scope vs feasibility.
- Ownership shift: the Co-create move from you owning the decision to the customer owning it. Deals move when the customer owns the decision.
Practice case: Northwind Logistics (fictional, for role play)
Use this case to practice the model end to end, or as a template for building a new fictional practice case for a different industry.
Profile: about $6 to 7B annual revenue, 25,000+ employees, North America and Europe, 3 segments (logistics, warehousing, last-mile).
Business context: Leadership is evaluating a solution/architecture (for example a Copilot rollout) to standardize AI and data across teams, but is not confident it will work across their current architecture. They have invested in analytics platforms and early AI use cases, but integration and consistency are unproven.
Entry point: A conversation with a senior technology leader (CIO), framed as: "We're considering this to standardize across teams, but we're not sure it'll work with our current architecture."
Signals already known: multiple teams running data/AI initiatives with some local wins; adoption and results vary widely across the organization; leadership flags inconsistent reporting, weak alignment, slow decisions.
What you don't know yet, by design: how data moves between systems; where integration and security/governance constraints are; whether real-time is actually required; what would need to be proven for them to feel confident.
Worked example, built using this framework:
Hypothesis: "In situations like this, where decentralized teams keep running independent AI pilots with no shared integration layer, and that window closes once architecture freezes ahead of peak season, Northwind's CIO and segment leaders experience stalled sign-off and inconsistent results that get more expensive to unwind every quarter it's left unresolved."
Stakeholders: CIO (wants a defensible, single architecture story, not another patchwork pilot) vs segment/BU ops leaders (want to keep the speed and autonomy of their local wins) vs IT/governance (wants to pause and standardize before scaling further). The conflict: segment leaders want to keep moving now, governance wants to slow down first, and the CIO is caught between them, likely why sign-off stalls.
Impact, so what three ways: costing today (duplicated pipelines per segment, inconsistent reporting slowing decisions); if nothing changes (enters peak season on fragmented, unproven systems, and every new local pilot hardens more incompatible patterns); where it's lost right now (time reconciling conflicting reports, money on redundant tooling, performance from inconsistent adoption). Directional number: industry research on fragmented enterprise data suggests 20 to 30 percent of data/analytics team time is lost to integration rework, delaying AI time-to-value by 6 to 12 months at large enterprises.
Reframe: not "which AI platform to standardize on," but whether Northwind proves integration, governance, and ownership on one high-value use case first (prototype-first), or commits to a fuller rollout now and resolves those questions as it scales.
Options: - Option A, Single-Thread Pilot: prove the pattern on one cross-segment use case before scaling. Fast proof, narrow scope. - Option B, Federated Rollout with Guardrails: segments keep moving, but adopt one shared minimum contract. Keeps speed, risks a half-adopted standard. - Option C, Ownership-First Governance: fix the decision-ownership gap before further technical investment. Fixes the root cause, delays a visible technical win.
Hidden info the customer reveals only when earned (for role play): no one clearly owns cross-team AI decisions (reveal only if the seller tests who signs off across teams); there is no shared integration layer or data contract (reveal only if the seller follows up on differently structured data and asks how data moves or is governed). The customer's one wrench to drop mid-conversation: "Honestly, I'm not sure this will even integrate with what we have," delivered without justification, testing whether the seller stays composed and holds their position.
Role play practice mechanic (3 roles, timed)
Use for group practice with Northwind or any case built the same way.
Roles: - Technical Seller: enters with the prepared hypothesis, leads with perspective not just questions, uses Curiosity's question stems to go deeper, test what's heard, and refine. Holds position long enough to earn a real reaction, does not abandon it the moment the customer pushes back. - Customer (executive): starts broad and incomplete, makes the seller earn the detail, reacts honestly (agree, push back, or question), drops one wrench or challenge mid-conversation without justifying it immediately. - Observer: captures, silently, what signal or word the seller caught, what assumption was being tested, how the seller deepened the conversation (go deeper, test, surface, or challenge), and what became clearer by the end that wasn't clear at the start.
Timing (adjust to the room): 7 minutes role play, 3 minutes individual reflect, 5 minutes group debrief.
Debrief questions: - Where did the seller recognize a signal, a word, a hesitation, something that didn't add up? - What assumption was being clarified? - What became clearer by the end that wasn't clear at the start?