SAP CPQ

How to Run a CPQ Discovery Workshop (Miro Board Included)

A senior adult programmer coding at home on a laptop, showcasing a work-from-home setup.

Most CPQ problems do not start in build or testing. They start much earlier, during discovery. Assumptions are made, requirements are implied, and complexity is underestimated. By the time issues surface, fixing them is expensive.

A CPQ discovery workshop is the single most effective risk-reduction step in a CPQ program. It aligns expectations, surfaces constraints, and forces decisions before they turn into rework.

Too often, discovery is treated as a formality. A few meetings, a slide deck, and a long list of features. What is missing is shared understanding. Sales talks about speed. Pricing talks about control. IT talks about integration. Everyone nods, but no one is aligned.

A well-run CPQ discovery workshop changes this dynamic. It creates a shared language across business, sales, and IT. Visual tools like a Miro board make assumptions visible, dependencies explicit, and gaps impossible to ignore.

From my experience, strong discovery does not slow projects down. It accelerates everything that follows. When scope is clear and risks are known, design becomes focused and delivery becomes predictable. This article explains how to run a CPQ discovery workshop that actually does that.

CPQ Discovery Workshop Explained

A CPQ discovery workshop is not a demo, and it is not a requirements document walkthrough. Its purpose is alignment, not solution design.

A CPQ discovery workshop exists to surface reality early. It exposes how sales actually sells, where pricing control is required, which rules are non-negotiable, and where complexity hides behind “edge cases”.

Discovery vs Solution Design

Discovery answers what and why.
Solution design answers how.

In discovery, the goal is to understand:

  • how quotes are built today
  • where errors, delays, and rework occur
  • which decisions must be enforced by CPQ

Jumping into solution design too early is one of the biggest CPQ risks. When teams start discussing screens, rules, or integrations before agreeing on scope and constraints, assumptions harden into bad design.

A good discovery workshop deliberately avoids detailed configuration discussions. It focuses on decisions, dependencies, and priorities.

Workspace with laptop, keyboard, smartphone, and notebook on a desk, representing preparation and collaboration during a CPQ discovery workshop session.

What Discovery Should and Should Not Do

Discovery should:

  • align stakeholders on goals and constraints
  • define in-scope and out-of-scope processes
  • identify risk areas early

Discovery should not:

  • finalize detailed rules
  • promise timelines
  • lock implementation choices

A successful CPQ discovery workshop creates clarity, not false certainty. It ensures that everyone leaves with the same understanding of what problem CPQ is expected to solve.

Who Should Be in the Room

A CPQ discovery workshop succeeds or fails based on who participates. Missing the right voices creates blind spots that surface later as rework, scope creep, or resistance.

CPQ discovery is a cross-functional exercise, not a sales-only conversation. CPQ sits between multiple disciplines, and each one brings constraints that must be understood early.

Sales: How Deals Really Happen

Sales participants provide reality. Not the official process, but how deals are actually closed under pressure.

They surface:

  • shortcuts used today
  • common exceptions
  • customer-driven complexity

Without sales input, discovery becomes theoretical. CPQ risks being designed for a process that does not exist in practice.

Young woman focused on laptop work in a modern cafe setting, surrounded by technology.

Pricing, Finance, and Operations: Where Control Matters

These roles define boundaries. They explain which rules are non-negotiable and where flexibility is acceptable.

Their input clarifies:

  • discount limits
  • approval requirements
  • compliance constraints

CPQ discovery without pricing and operations creates future conflict. Rules added later always feel heavier than rules agreed upfront.

IT and Governance: What Is Feasible and Sustainable

IT does not need to dominate discovery, but it must be present.

They help identify:

  • integration constraints
  • data ownership
  • architectural guardrails

Early IT involvement prevents discovery from producing unrealistic expectations. It keeps scope grounded and sustainable.

The Real Risk of Missing Stakeholders

When key roles are absent, decisions are deferred. Deferred decisions do not disappear. They resurface during build, testing, or go-live, when changes are most expensive.

A strong CPQ discovery workshop prioritizes representation over speed. Fewer surprises later always outweigh a faster meeting today.

Structuring the CPQ Discovery Workshop

A CPQ discovery workshop does not succeed because it lasts longer. It succeeds because it is structured intentionally. Without structure, discussions drift, dominant voices take over, and critical topics get postponed.

A well-structured CPQ discovery workshop protects focus and forces decisions. Time-boxing is not about rushing. It is about prioritizing what truly matters.

Software developer typing code on dual monitors at a wooden desk.

Sequencing Topics the Right Way

Discovery works best when topics follow a logical progression.

Start with:

  • business goals and success criteria
  • current quoting process and pain points

Only then move into:

  • pricing and approval boundaries
  • configuration complexity and exceptions

Starting with features instead of process leads to shallow discovery. Teams end up shopping for functionality instead of understanding what must change.

Time-Boxed Agenda Blocks

Each discovery block should have a clear purpose and outcome.

For example:

  • map current-state quoting flow
  • identify top risk areas
  • agree on in-scope vs out-of-scope

Time-boxing forces clarity. When time is limited, participants focus on decisions instead of debates.

Unresolved topics should be parked intentionally, not debated endlessly.

Decisions Over Documentation

The goal of discovery is not to document everything. It is to decide what matters.

A strong workshop prioritizes:

  • decisions that affect scope
  • assumptions that need validation
  • risks that require mitigation

Good discovery creates alignment, not paperwork. Documentation comes later, informed by shared understanding instead of fragmented notes.

When structure is right, the workshop feels intense but productive. Everyone knows why each topic exists and what outcome is expected.

Close-up of hands typing on a laptop placed on a wooden table outdoors.

Using a Miro Board for CPQ Discovery

CPQ discovery fails most often because people talk past each other. Everyone uses the same words, but means different things. Visual collaboration removes that ambiguity.

A Miro board turns CPQ discovery from discussion into shared understanding. Instead of abstract conversations, assumptions are placed on the board where they can be challenged, refined, and aligned.

Making the Invisible Visible

Processes, dependencies, and exceptions are hard to grasp in conversation alone.

On a Miro board, teams can:

  • map the current quoting flow
  • highlight pain points and delays
  • visualize approvals and decision points

When workflows are visible, gaps become obvious. What felt like a minor exception suddenly shows up as a major detour in the process.

Aligning Vocabulary and Expectations

One of the biggest risks in CPQ discovery is semantic mismatch. Sales, pricing, and IT often use the same terms differently.

A shared board forces alignment:

  • what “quote” actually means
  • where pricing decisions happen
  • when approvals are triggered

Visual alignment prevents misunderstanding from turning into design defects. Everyone literally points to the same thing.

Capturing Decisions, Not Just Notes

Notes get lost. Decisions stick when they are visible.

A good CPQ discovery board clearly shows:

  • agreed scope
  • open questions
  • assumptions to validate

The board becomes a living artifact of the workshop. It replaces fragmented notes and ensures continuity after the session ends.

Close-up of a programmer typing on a laptop, displaying code on the screen.

Why Miro Works Especially Well for CPQ

CPQ spans processes, rules, and exceptions. Miro supports this mix naturally.

Visual discovery accelerates alignment across disciplines. Instead of debating interpretations, teams converge on a shared model faster.

The result is not just a better workshop, but a stronger foundation for everything that follows.

Outputs That Matter

A CPQ discovery workshop is successful only if it produces clear, actionable outputs. Insight without output is just a conversation.

The goal of a CPQ discovery workshop is decision clarity, not documentation volume. When outputs are right, design and implementation become faster and more predictable.

Agreed Scope and Boundaries

One of the most important outputs is a shared understanding of scope.

This includes:

  • what CPQ will cover
  • what is explicitly out of scope
  • which scenarios are deferred

Clear scope prevents silent assumptions from turning into future conflict. When boundaries are visible and agreed, scope creep loses its power.

Key Decisions and Non-Negotiables

Discovery should surface decisions that shape the solution.

Examples include:

  • pricing control boundaries
  • approval requirements
  • mandatory compliance rules

These decisions guide every design choice that follows. Without them, teams fill gaps with assumptions.

A strong workshop makes these decisions explicit and visible.

Woman in focus working on software development remotely on laptop indoors.

Risks and Assumptions

No CPQ discovery is complete without acknowledging uncertainty.

Good outputs include:

  • identified risk areas
  • assumptions that need validation
  • dependencies on external systems or teams

Naming risks early reduces their impact later. What is visible can be managed. What is hidden becomes expensive.

A Shared Reference Point

Finally, discovery must leave behind a single reference artifact.

This is often the Miro board itself:

  • capturing process flow
  • marking decisions and open questions
  • showing alignment across roles

A shared reference prevents re-interpretation after the workshop. It anchors future discussions in what was actually agreed.

When these outputs exist, discovery delivers its true value. It creates momentum instead of ambiguity.

Common Discovery Workshop Mistakes

Most CPQ discovery workshops fail quietly. They feel productive, everyone participates, and notes are taken. The problems only appear later, during build or testing, when assumptions turn into rework.

Weak CPQ discovery creates false confidence instead of real alignment.

Feature Shopping Instead of Process Discovery

One of the most common mistakes is turning discovery into a feature discussion.

Teams jump too quickly into:

  • what CPQ can do
  • which features are needed
  • how screens should look

When discovery focuses on features, underlying process problems remain hidden. CPQ ends up automating existing chaos instead of fixing it.

Strong discovery stays anchored in process, decisions, and constraints.

Missing or Silent Stakeholders

Another frequent issue is incomplete participation.

Key roles may be missing, or present but silent. Decisions are deferred with phrases like “we’ll confirm later”.

Deferred decisions always come back at the worst possible time. Missing voices in discovery translate directly into change requests during implementation.

A good workshop actively pulls in perspectives and forces clarity, even when it is uncomfortable.

A vibrant workspace showing computer monitors with code, keyboard, and tech accessories.

Trying to Solve Everything in One Session

Discovery is not meant to solve every problem.

Some teams attempt to:

  • define all rules
  • agree on every exception
  • finalize future phases

This overwhelms the session and dilutes focus. Instead of clarity, the outcome is exhaustion and vague agreement.

Effective CPQ discovery prioritizes what must be decided now and clearly parks everything else.

No Clear Output Ownership

A final common mistake is not defining ownership of outputs.

If no one is responsible for:

  • validating assumptions
  • finalizing scope
  • carrying discovery insights forward

then alignment decays quickly.

Discovery without ownership is a missed opportunity. Momentum fades, and teams reinterpret outcomes differently.

Avoiding these mistakes does not require more meetings. It requires discipline, focus, and respect for what discovery is meant to achieve.

Final Thoughts

A CPQ discovery workshop is not about collecting requirements. It is about creating shared understanding before decisions become expensive to change.

A well-run CPQ discovery workshop reduces risk by forcing clarity early. It aligns business goals, exposes real complexity, and replaces assumptions with visible decisions. This is what prevents scope creep, rework, and frustration later in the project.

Visual collaboration plays a critical role. Tools like a Miro board turn abstract discussions into concrete artifacts. Processes, constraints, and risks become visible, shared, and hard to ignore. When everyone sees the same picture, alignment happens faster and lasts longer.

The biggest value of discovery is momentum. When scope is clear, risks are named, and ownership is defined, implementation becomes focused instead of reactive. CPQ stops being a leap of faith and becomes a controlled journey.

In my experience, teams that invest properly in discovery rarely regret it. They build faster, argue less, and deliver CPQ solutions that actually match how the business sells. That is the real return of a strong CPQ discovery workshop.