Discovery & Framing / A working perspective by Rob Urban
Solving the right problem starts with the right question.
Solving any problem starts with understanding what the true problem is. Everything that follows depends on how honestly and carefully we do that work.
A business can spend a remarkable amount of money answering a question nobody should have accepted in the first place.
Which platform should we buy? How do we get more leads? Where can we add AI? How quickly can we expand? Each question sounds practical. Each contains an assumption about what is wrong or what deserves investment. If that assumption survives unexamined, a capable team can deliver exactly what was requested and leave the important problem untouched.
I want to know what produced the request.
What happened? Who experienced it? What were they trying to accomplish? How do we know the difficulty is occurring for the reason we think it is? What would become possible if we understood it differently?
Those questions are the beginning of discovery and framing. Discovery is the investigation that helps us understand a situation. Framing turns that understanding into a clear description of the challenge or opportunity, the evidence behind it and the decision that needs to follow.
The distinction matters. A room can contain a great deal of information and still have no useful agreement about what it means. Good framing gives the information a purpose without forcing it to support an answer chosen in advance.
The “true problem” is not always one hidden cause waiting to be discovered. Large organizations have interacting conditions: incentives, capacity, information, authority, technology and customer expectations. A useful investigation may reveal several causes, a tradeoff or a problem whose boundaries were drawn in the wrong place.
I am looking for the most defensible understanding we can reach, with the remaining uncertainty visible. That is a stronger foundation than a confident explanation assembled from the first three conversations.
For an opportunity, the same discipline applies. Something does not have to be broken to deserve attention. We may be considering a new market, an unused capability, a partnership or a better service. Then I want to understand who would benefit, why they would value it and what evidence would justify the next commitment.
The first move
Take the request seriously enough to question it.
A leader asking for a new CRM may have spent months watching opportunities disappear between departments. I would not dismiss the request as a symptom and congratulate myself on being strategic. There is usually a reason an intelligent person arrived at that answer.
I would ask them to walk me through it. What have they seen? What have they already tried? Which part of the current process cannot support the work? What would the replacement allow someone to do differently?
That approach respects the person’s knowledge while leaving the proposed solution open to examination. They may be right about the CRM. They may be right about the difficulty and mistaken about its cause. Discovery should make either conclusion possible.
My independence matters here. If every conversation ends with a recommendation for the same product, the investigation has become a sales exercise. I want the freedom to recommend a smaller change, a different priority, more evidence or no purchase.
Preparing to learn
Arrive with a provisional explanation.
Be willing to lose it.
Preparation should make the conversation more useful. I review the organization’s purpose, operating environment, customer or user experience, relevant systems, known constraints and the decision under consideration. I also ask what has already been investigated so we do not charge people another meeting to repeat work they have done.
Then I separate what appears established from what is inferred. A reported backlog is an observation to verify. “We need more staff” is a proposed explanation or response. “The delay sits in approvals” is a hypothesis we can test.
I prefer a small set of competing explanations. If a service is slow, the work may require more capacity, arrive incomplete, wait for authority, travel through unnecessary steps or depend on unreliable information. Those possibilities suggest different evidence and different participants.
The hypothesis is useful because it focuses the investigation. It becomes dangerous when the team starts looking only for confirmation. I want to write down what would make us change our minds.
A question that protects the investigation
If our preferred explanation were wrong, what would we expect to find in the records or hear from the people doing the work?
Before a session, I also establish what decision the work is meant to inform. Are we deciding whether to invest in further research, authorize a pilot, change a process or begin procurement? Those decisions need different levels of confidence. A discovery engagement should have a boundary and a purpose.
Learn what an ordinary day requires.
I want to understand the organization in its own language. What does a successful day look like? Which commitments are time-sensitive? Where are the consequences of failure serious? What does “ready,” “qualified,” “resolved” or “available” mean to the people responsible?
A reservations manager, plant supervisor and public-service operator may all describe a capacity problem while dealing with very different constraints. Familiar business terminology can conceal unfamiliar operating realities. I would rather ask someone to explain a term than build an elegant recommendation around a mistaken definition.
I start with recent examples. Show me the last difficult request. Show me one that went smoothly. Show me where the information arrived, where the work waited and what the next person needed. Include the spreadsheet, phone call and handwritten note if they are part of the actual process.
Workarounds deserve particular attention. They often preserve something valuable that the formal system cannot support. Removing one without understanding its purpose can make a process look cleaner while making the work harder.
- “What happened the last time?”
Moves the conversation from a general impression to an event we can examine. - “When does this go well?”
Reveals conditions that may distinguish a functioning process from a failing one. - “What do you have to do that the official process leaves out?”
Brings hidden work into view without treating the person doing it as the problem. - “Who experiences the consequence after it leaves your team?”
Extends the investigation beyond a departmental boundary.
There is no universal script that can replace attention. A good question changes what I ask next.
From accounts to evidence
A convincing explanation still needs to survive a check.
Interviews tell me how people understand the situation. Records show selected parts of what happened. Observation reveals work that neither may capture. I want those perspectives in conversation with one another.
Suppose a manager says approvals take too long. I would examine actual timestamps, the definition of a complete request, the number of returns for clarification and who was authorized to decide. A request submitted on Monday and approved on Friday did not necessarily spend four days awaiting approval. It may have spent three days awaiting information.
I would also look for cases that do not fit. The same approver may complete one category quickly and another slowly. That difference can reveal a policy ambiguity, a missing input or an exception requiring specialist judgment. Averages can make distinct problems appear to be one.
My work on root-cause analysis and business analytics examines how data helps with that investigation. Discovery and framing also asks who defines the issue, whose experience is missing and what decision the evidence can reasonably support.
Ask why without turning the conversation into an interrogation.
The Five Whys technique described by ASQ encourages looking beneath an initial explanation. The number is not a quota; ASQ notes that an investigation may require fewer or more questions.
In practice, I vary the question. What made that necessary? What information was available then? What prevented an earlier decision? Which condition would have to change for the outcome to be different?
I do not treat a sequence of plausible answers as proof. Several causes may branch from the same event. A person’s account may be incomplete. “Human error” may describe the last visible action while leaving the interface, workload or conflicting instructions unexplored.
The stopping point should be a meaningful, testable explanation at a level where action is possible. We can record wider conditions without pretending an engagement can resolve the entire economy or redesign an industry.
Keep these distinctions visible
An observation is what we have seen. An interpretation is what we think it means. A hypothesis proposes an explanation we can test. A decision is what we are prepared to do with the evidence available.
This also protects against false precision. If impact is uncertain, I use a range and state the assumptions. If data is missing, that becomes an evidence gap with an owner. A confident number should not be the entrance fee for being taken seriously.
A worked discovery example
The request is proposal automation.
The difficulty may be deciding what can be promised.
The following company and figures are illustrative. They show the reasoning process, not a client deployment or a measured result.
Imagine an industrial supplier whose proposals take too long. Leadership asks whether AI can write them faster. The sales team supports the idea because buyers sometimes stop responding before a quote is ready.
I would begin by tracing recent proposals from inquiry to release. Suppose an initial sample shows a median elapsed time of nine business days, while drafting occupies about three hours of active work. That does not make drafting irrelevant. It tells us that writing speed alone cannot explain the elapsed time.
We would need to inspect the intervals. Perhaps incomplete specifications produce repeated clarification. Perhaps nonstandard configurations wait for engineering review. Perhaps commercial approval is quick for standard pricing and slow when a salesperson has already suggested an exception.
I would then compare standard and nonstandard requests, complete and incomplete submissions, new and repeat customers, and successful and unsuccessful proposals. We should also check whether the sample reflects the normal workload. A month dominated by unusual orders could give us the wrong picture.
| Possible explanation | Evidence to examine | What would weaken it? |
|---|---|---|
| Writing is the bottleneck | Active drafting time and its share of total elapsed time. | Most delay occurs before drafting can begin. |
| Requests arrive incomplete | Missing inputs, clarification cycles and elapsed time by completeness. | Complete submissions experience comparable delays. |
| Exceptions wait for authority | Decision queues, approval limits and standard versus exceptional requests. | Authorized decisions are made promptly but fulfillment checks still stall. |
A provisional frame might now describe a coordination problem: sales cannot provide a dependable commitment until technical feasibility, inputs and commercial authority are resolved. We would validate that explanation with the people who perform those decisions and test it against additional cases.
A more useful problem statement
For nonstandard inquiries, the team cannot consistently establish a complete, technically reviewable request and a clear approval route. Buyers wait without a dependable proposal date. We need to identify and reduce the avoidable waiting while preserving technical accuracy and commercial control.
This frame leaves several solutions available. Better intake, clearer decision authority, protected review capacity and drafting assistance may all have a place. It also identifies what must be measured before we promise a result.
Success could mean shorter elapsed time for a defined class of complete requests, with no increase in pricing errors, unsupported commitments or downstream rework. The baseline and target would be agreed after the measurement definitions and evidence are sound.
That is the value of discovery. It gives a proposed technology an honest job to do.
Different settings. Different questions.
The opportunity changes when the question becomes more precise.
The following scenarios illustrate how I would approach discovery across several business and organizational settings. They are not claims about specific client engagements. Each begins with an understandable request and follows it toward a more useful decision.
Luxury hospitality / Demand and commercial fit
“We need more bookings” may be too broad to help.
A hotel can be full on peak weekends and still struggle commercially. More bookings during those weekends may create little additional value. The real opportunity might concern quieter weekdays, a room category that is difficult to sell or guests whose expectations do not match the property.
I would examine demand by date, segment, source, room type, booking window and net contribution where reliable data permits. Then I would speak with reservations and operations. Which guests are a particularly good fit? Which inquiries are declined? Which promises create avoidable service recovery?
The discussion might reveal an opportunity to serve small midweek retreats. Before recommending a campaign, I would investigate whether the property has the space, staffing, food service and sales process to fulfill that demand profitably.
Which additional stays would improve the business, and can the hotel deliver the experience those guests need?
That question makes marketing, revenue management and operations part of the same investigation. It also protects the qualities existing guests value. Growth that makes the hotel less enjoyable is a tradeoff to examine explicitly.
Museums / Cultural institutions / Public value
A popular building can still be missing part of its mission.
Imagine a museum with healthy total attendance and declining school participation. A larger advertising campaign may increase the headline number while doing little for the educational objective.
I would want to understand the teacher’s entire decision. How does a visit fit the curriculum? When must it be approved? What does transportation require? How much work is involved in booking, permissions and accessibility planning? What happened with schools that considered a visit and decided against it?
Internal interviews matter too. Educators may have spare capacity at times that schools cannot use. The booking team may lack information teachers need before seeking approval. An enthusiastic teacher may be unable to authorize spending.
The frame could become an access and coordination problem for a specific group of schools, rather than an awareness problem for the general public. A small test of booking support or a partnership may teach us more than a broad promotional investment.
What would make this educational experience realistically usable for the schools the institution wants to serve?
Enterprise software / Retention and product value
A customer-success problem may begin before the contract is signed.
A software business sees weak adoption and asks for a new customer-health dashboard. The dashboard could make a real contribution. First I would ask what behavior we need to understand and what someone could do when the signal changes.
Discovery would follow customers from sales expectations through implementation and first useful outcome. Did the buyer and the day-to-day users want the same thing? Were required integrations available? Did anyone own the internal process change? Did the account receive a product that could support the promised use?
I would compare customers who reached value with those who stalled, while recognizing that the groups may differ in ways unrelated to onboarding. Interviews with disengaged users and lost accounts can challenge the story told by the most enthusiastic customers.
If the evidence points to unresolved implementation ownership, a dashboard alone will mostly provide a better view of delay. If certain expectations cannot be met, the commercial and product decisions need attention.
What must happen for the customer to receive the value they purchased, and where does that sequence break down?
Professional services / A promising new market
Interest is useful evidence.
It is not yet a market.
A professional firm has received several inquiries from a new industry. Leadership sees an opportunity to create a dedicated practice. Discovery should investigate the opportunity with the same discipline we apply to a recurring failure.
I would distinguish casual interest from a costly, important need. What are prospective clients doing today? Who owns the consequence of the problem? Who can commission help? What would make a new provider credible? Why would a client change from an existing relationship?
The firm also needs to examine its own capacity. Expertise may be transferable, but the new sector may require different delivery practices, evidence, partnerships or commercial terms. The opportunity is less attractive if it depends on one already overcommitted principal.
A useful next step might be a bounded offer tested with a small number of qualified prospects, with explicit learning goals. It could also be a partnership or a decision to defer. Discovery can preserve an attractive idea while reducing the size of the first bet.
Which customer problem can we credibly solve, and what evidence would justify building a practice around it?
Complex institutions / Secure operational environments
The person who needs the capability may not control its arrival.
Consider an organization that needs operational information available during intermittent connectivity. The initial request might be for a different hosting platform. The underlying requirement may concern continuity, approved access, data freshness and recovery when a connection returns.
I would ask operators to describe the decisions they must make, how long information remains useful, what happens when it is unavailable and which current workarounds preserve the operation. Technical and security owners would establish constraints. The responsible acquisition and funding teams would explain the actual route to authorization.
That investigation should happen within approved information-sharing boundaries. It does not require collecting sensitive details unnecessarily. We need enough shared understanding to define the capability, test feasibility and identify the evidence each decision owner requires.
A technically appealing option may be unusable within the operating constraints or impossible to acquire on the assumed schedule. Neither condition should be discovered at the final presentation.
What capability must remain available, under which conditions, and what decisions are required to make that possible?
People, authority and the path forward
The problem has an operating system made of people.
Understanding the workflow is only part of the assignment. I also need to understand how the organization makes decisions about it.
The person who experiences a problem may be unable to fund its solution. A sponsor may control funding but not the policy causing the delay. A technical team may be accountable for reliability while a commercial team promises exceptions. A procurement specialist may understand a timing constraint nobody has included in the roadmap.
I map these responsibilities in plain language. Who depends on the outcome? Who owns the process? Who can authorize a change? Who supplies evidence? Who has to operate the result? Whose agreement is required, and what will they need to see?
I avoid reducing people to obstacles. Resistance can reveal a legitimate duty or a consequence the proposal has overlooked. The useful question is what that person is protecting and whether the design can respect it.
A productive workshop does not require everyone to agree immediately.
Some conversations are better held individually before the group meets. People may be reluctant to describe a workaround, challenge a definition or name a capacity problem in front of a senior sponsor. I want the session to benefit from those realities without turning private comments into attributed accusations.
During the working session, I separate observations from explanations, invite quieter participants and make disagreements explicit. If sales says a request is complete and operations disagrees, I ask each team to define completion using a real example. That gives us something more useful than asking them to improve communication.
Before closing, I read back the proposed frame. Does it reflect the work? What have I misunderstood? Which part remains unverified? What would each participant need to approve the next step?
Validation does not mean unanimity or ceremonial sign-off. It means the people affected can recognize the situation, correct the record and see which disagreements remain. Someone must own the decision when priorities genuinely conflict.
Making the value measurable
Define the distance between today and better.
A useful frame identifies who is affected, what they are trying to accomplish, where the current state falls short and why the difference matters. It separates demonstrated causes from suspected ones. It describes the desired outcome without quietly prescribing the solution.
Measurement begins with definitions. What starts the clock? What stops it? Which cases are included? Does “complete” mean sent, accepted or successfully used? Who maintains the baseline, and can the measure be reproduced?
For a service process, I might examine elapsed time, active effort, failure or rework, reliability and the effect on the person waiting. For an opportunity, I might examine qualified demand, willingness to commit, delivery feasibility and the economics of serving it.
Financial impact needs the same care. Hours released are not automatically cash savings. Delayed revenue is not automatically lost revenue. Avoided effort, increased capacity and improved contribution should be shown separately, with overlap removed from the calculation.
I also ask about the cost of leaving the situation alone. It may be substantial, modest or uncertain. The status quo belongs among the alternatives, with maintenance and deterioration included where evidence supports them. Invented urgency does not improve a business case.
A good success condition protects what matters
Reduce the waiting experienced by a defined group of customers while maintaining accuracy, dependable commitments and a workload the team can sustain.
The exact target comes from the baseline, the importance of the outcome and what the team can credibly test. We should also name effects that would make the change unacceptable. Faster processing is a poor result if it transfers avoidable work to another department or makes errors harder to detect.
For large opportunities, I look for the assumption most capable of invalidating the investment. If customers will not commit, a detailed delivery plan cannot rescue the proposition. If a required capability is technically uncertain, another round of enthusiastic interviews may add little. The next investigation should address the uncertainty that matters most.
What the engagement should leave behind
A short readout that makes the next decision easier.
After a complex discussion, the output should be clearer than the conversation. I want an executive readout concise enough to use, with supporting evidence available for the people who need to inspect it.
Below is an illustrative decision brief for the proposal example. It is deliberately provisional where discovery has not yet established a fact. A polished document should never make weak evidence look settled.
Illustrative discovery brief / Proposal turnaround
- The situation
- Buyers requesting nonstandard configurations cannot receive a dependable proposal date. Sales and review teams lack a shared definition of a ready-to-review request.
- What we know
- The initial sample shows nine business days of median elapsed time and about three hours of active drafting. Sample coverage and interval definitions still require validation.
- What may explain it
- Incomplete inputs, technical-review queues and exception authority are candidate contributors. Their relative impact has not yet been established.
- The desired change
- Reduce avoidable waiting for a defined request category while preserving technical and pricing accuracy.
- Who must decide
- The sales and operations owners agree on readiness; engineering validates review requirements; the commercial authority approves changes to exception handling.
- The next evidence
- The analyst separates waiting intervals and compares complete and incomplete requests. Process owners review examples that contradict the leading explanation.
- The commitment
- Before the session ends, assign named owners and calendar dates for the evidence review. At that review, decide whether to test a bounded process change, investigate further or redirect the work.
For a larger investment, the readout also captures the funding owner, spending route, relevant contractual or procurement steps, decision criteria, competing options and timing constraints. These should be confirmed by the people responsible. An available budget does not by itself establish a viable path to execution.
The technical team remains involved early enough to surface feasibility issues. Detailed solution design can then proceed against a frame that the organization understands. Discovery and engineering inform each other; they do not need to wait behind a rigid handoff.
A successful engagement can result in proceeding, narrowing the scope, testing an assumption, changing priorities or deciding the opportunity is not worth pursuing. Each can be a valuable outcome when the reasoning is sound.
Leading Discovery & Framing
Own the discipline.
Stay close to the difficult work.
Leading a Discovery and Framing function means being accountable for the quality of the decisions it makes possible. I would own the methodology, engagement standards, staffing model and customer-facing synthesis, while personally leading the situations with the greatest ambiguity, consequence or executive sensitivity.
That hands-on involvement matters. It exposes where the method is weak, where practitioners need support and where a familiar question no longer fits. I would remain involved in critical interviews, contested problem frames and important readouts, with a clear plan for developing other people to lead comparable work.
The function also needs an explicit mandate. Which assignments qualify for discovery? Who can request help? How are competing requests prioritized? Who can challenge an opportunity that leadership wants to advance? I would establish those answers with the executive sponsor before promising capacity the team does not have.
I would protect independence in performance reviews as well as in conversation. A practitioner who demonstrates that an opportunity should stop has done useful work. If the only rewarded outcome is progression toward a sale, people will learn to soften inconvenient findings.
My responsibility would include making the practice useful to the wider organization: clear entry points, proportionate engagement options, dependable outputs and a visible path from investigation to a decision.
Building the methodology
Define what must be learned, then design the work around it.
I would start with a small number of representative engagements and turn their lessons into a working method. A narrow diagnostic, an unfamiliar market opportunity and a complex institutional decision should not receive an identical agenda. They should meet a common standard for evidence, clarity and accountability.
The engagement model would distinguish a focused review from a broader investigation. Scope would reflect the stakes, uncertainty, stakeholder access and decision being supported. Before work starts, the sponsor and practitioner should understand the question, boundaries, expected participation, deliverable and conditions that could require more investigation.
The method needs explicit checkpoints. Preparation ends with a research plan and competing explanations. Investigation produces observations, tested assumptions and unresolved questions. Synthesis connects the evidence to a proposed frame. Customer validation corrects that frame. The decision review establishes what happens next and who accepts responsibility.
These are checks on the quality of the work, not compulsory meetings. A simple assignment may cover several in one conversation. A consequential investment may need multiple rounds. When evidence changes the question, the plan changes with it.
| Material | What it helps the team do |
|---|---|
| Engagement playbook | Choose an appropriate scope, research approach and review path for the decision and its consequences. |
| Question bank | Explore causes, impact, constraints and authority, with prompts explaining when a question is useful and what evidence to seek next. |
| Evidence record | Connect a claim to its source, date, limitations, verification state and any conflicting evidence. |
| Examples and review criteria | Show the difference between a polished description and a defensible frame, using permitted, appropriately anonymized work. |
| Decision brief | Present the validated situation, alternatives, remaining uncertainty, recommendation and next commitment in a consistent, readable form. |
I would version these materials and give someone responsibility for maintaining them. New practitioners need to know which guidance is current. Experienced practitioners need a route to challenge it. Repeated exceptions are evidence that the method may need to change.
Frameworks in their proper place
Use MEDDPICC to examine the path to a decision.
For a complex commercial opportunity, MEDDPICC provides a useful qualification structure. Its elements cover metrics, the economic buyer, decision criteria, the decision process, the paper process, the problem and its implications, a champion, and competition.
In plain language, I want to understand the value at stake, who can authorize spending, how alternatives will be judged, how the decision will be made, which formal steps follow, why the issue matters, who can help the organization act, and what else it could choose. Those questions connect the discovery findings to commercial reality.
MEDDIC and MEDDICC are related variants. For an assignment involving procurement and contracts, I would make the paper process explicit regardless of the terminology used internally.
A completed qualification record does not establish that we have diagnosed the customer’s problem. I would keep the evidence behind the fields visible. A supportive contact is not automatically an effective internal advocate. A budget conversation is not authorization. A stated decision date needs to be reconciled with the actual approvals.
For example, an operations director may validate the need while a separate executive controls spending, security needs additional evidence and procurement cannot begin until a requirements owner accepts the scope. The opportunity is understandable, but the route to action remains incomplete. That should be apparent before anyone commits a delivery team.
I discuss the broader selection problem in Business Analysis Frameworks: Choose the Question Before the Acronym. In discovery, different methods help with different uncertainties:
| Method | Where I would use it | What still needs judgment |
|---|---|---|
| Hypothesis tree | Separate plausible explanations and plan evidence that could distinguish them. | Whether the branches omit an important cause or assume the answer. |
| Journey or process mapping | Trace the experience across people, systems, waiting and handoffs. | Whether the map reflects actual work, including exceptions. |
| Five Whys | Investigate beneath an initial explanation. | Whether each proposed cause has support and whether causes branch. |
| MEDDPICC | Examine a complex opportunity’s value, participants and buying path. | Whether qualification reflects verified reality and a legitimate fit. |
| RACI | Clarify who is responsible, accountable, consulted and informed for defined activities. | Whether the named people have the authority and capacity to act. |
| ADKAR | Examine the people-side requirements of a proposed change. | What practical support each affected group needs. |
Prosci’s ADKAR model addresses awareness, desire, knowledge, ability and reinforcement. I would bring that perspective into discovery when adoption could determine whether an otherwise sound proposal succeeds. Training cannot compensate for a role that has no time or authority to use the new process.
These tools support the investigation at different points. I would not make every engagement complete every framework. The choice should improve a decision enough to justify the effort.
Systems, SOPs and process
Build enough structure to make good work dependable.
A methodology explains how we investigate and judge. A process describes the sequence, responsibilities and handoffs. A standard operating procedure explains how to perform a repeatable activity. Systems hold the information and support the work. Each has a role; none can supply a missing diagnosis.
Some operating rules belong in place from the beginning: how an engagement is accepted, how access is approved, how evidence is recorded, how customer information is handled and how findings receive review. Those protect the work while the method is still developing.
More detailed SOPs should grow from observed, useful practice. I would document the steps that need consistency, including inputs, owner, completion criteria, exception handling and review date. I would leave room for professional judgment in interviews and synthesis. A question bank should help someone listen better, not require them to ignore an important answer because the script has moved on.
For the systems, I would establish a clear home for each kind of record. The CRM can hold relationship and opportunity status. An approved evidence repository can hold supporting material. A decision log can record the accepted frame and why it changed. The work tracker can assign actions and dates. Shared identifiers and links are often more useful than copying every note into every application.
Access and retention should follow the organization’s information policies. Sensitive interview material does not belong in a broadly visible sales record simply because it influenced the analysis. Summaries should preserve what decision-makers need while respecting appropriate boundaries.
When discovery recommends changing a customer’s process, I would first validate the new operating approach in a proportionate test. Then the process owner can approve the SOP, training and system changes needed to sustain it. Automating an untested procedure can make an early mistake expensive to unwind.
Building and scaling the team
Plan for the work around the workshop.
I would forecast demand by engagement type and estimate the full effort: preparation, interviews, analysis, facilitation, synthesis, review, validation and follow-through. A two-hour executive session may depend on days of work that never appear on the customer’s calendar.
The staffing model needs skills as well as hours. Facilitation, industry knowledge, analysis, technical interpretation and executive writing are different capabilities. Hiring another generalist may not help if every engagement is waiting for one senior reviewer or one specialist.
Illustrative capacity calculation, not a staffing benchmark
Three practitioners with 100 available delivery hours each provide 300 hours in a month. Reserving 60 hours for uncertainty leaves 240 planned hours. Eight engagements averaging 24 hours require 192 hours, leaving 48 planned hours unallocated.
The apparent headroom can conceal a bottleneck. If each engagement’s 24 hours includes three hours of senior review, the team needs 24 review hours. A lead with only 18 hours available cannot support that plan unchanged. I would reschedule, adjust scope, develop review capability or add qualified capacity rather than assume the aggregate total solves the problem.
The numbers above are hypothetical. Actual planning would use observed effort, variation, leave, internal commitments and the maturity of the team. I would also track work in progress and waiting time. Starting more engagements can worsen throughput if unfinished synthesis and approvals accumulate.
I would build the team in stages: establish the standard through a small number of closely led engagements, develop practitioners through paired delivery and reviewed assignments, then expand independent ownership as their work demonstrates readiness. Hiring follows a sustained capability or workload gap, not one unusually busy week.
As the practice grows, domain leads can provide specialist depth while shared review standards keep outputs consistent. I would retain personal involvement in the hardest work and use it to improve the method, without making myself the mandatory reviewer for every routine decision.
The path to action
Leave with a commitment someone has accepted.
A discovery readout becomes useful when the customer and delivery organization know what follows from it. That might be a focused feasibility test, a process experiment, a funded design stage or a decision to stop. “Continue the conversation” is too vague to govern work.
I would bring the accepted problem frame, baseline, alternatives, evidence gaps and decision criteria into a working agreement. Each next step needs an owner, a date, a dependency and a clear completion condition. The customer should know what they are committing; the delivery team should know what it is accepting.
Responsibilities need to remain distinct. Account leadership owns the relationship and commercial follow-through. The discovery lead owns the integrity of the investigation and readout. Practitioners own their assigned research and synthesis. Technical leadership owns feasibility, architecture and technical validation. Customer process owners accept changes to operations. Sales leadership and enablement support consistent use of the method and reinforce evidence-based qualification.
Funding and formal authorization require their own checks. Who can release the budget? Which scope must be approved? What evidence do procurement, security or legal reviewers need? What dates are real constraints? Those owners should confirm the route rather than inherit assumptions from a project plan.
For the proposal-delay example, the next commitment could be a bounded test of a revised intake process for one request category. Sales owns the intake change, engineering confirms the required inputs, the analyst measures elapsed time and rework, and the sponsor reviews the evidence on an agreed date. A wider rollout follows only if the result warrants it.
When the work enters delivery, I would carry the problem statement, success conditions and unresolved assumptions into the backlog, acceptance criteria and operating handover. Otherwise the implementation can drift toward completing features while losing the improvement that justified them.
The practice should learn from what happens next. Were the important constraints identified early? Did the customer accept the frame? Did the chosen action improve the outcome? Which assumptions failed? Those answers feed back into the playbook, staffing plan and coaching. That is how discovery becomes an organizational capability with consequences beyond the workshop.
When discovery becomes a capability
Scale the quality of judgment.
In an organization handling many complex engagements, I would establish shared standards for preparation, evidence, facilitation and the final readout. A common structure makes quality easier to review. It should still leave practitioners room to notice something the template did not anticipate.
I would coach people using real engagement work: the assumption they failed to test, the question that opened up an important issue, the participant they missed and the claim that outran its evidence. Peer review can strengthen a frame before it becomes an executive recommendation.
Capacity planning should account for research, synthesis, validation and follow-through as well as meeting time. Otherwise the organization rewards the visible session and starves the work that makes it useful.
I would assess the function by whether stakeholders recognize the problem, whether decisions have better evidence and whether fewer important constraints appear late. A high volume of workshops says little on its own.
The purpose is a repeatable level of care, applied with enough curiosity to fit the situation.
Before the first working session
Questions about discovery and framing.
How is discovery different from gathering requirements?
Requirements describe what a proposed capability must do. Discovery examines the situation that makes a capability worth considering, including whether the request identifies the right problem. They inform one another, but a complete requirements list can still describe a solution to the wrong issue.
How much discovery is enough?
Enough to make the next decision responsibly, with the remaining uncertainty understood. The depth depends on the consequences, reversibility and cost of being wrong. I would timebox the investigation, agree on decision criteria and stop collecting information that is unlikely to change the next action.
What if the organization already chose a solution?
I would examine the outcome it is expected to improve and the assumptions supporting that expectation. The decision may be well founded. If there are gaps, the work can define a pilot, adjust scope or establish conditions for continuing before more is committed.
Can discovery help when nothing is obviously broken?
Yes. It can clarify an opportunity, identify who would value it, test the conditions required for success and define an affordable next experiment. The aim is to understand what makes the opportunity worthwhile before treating enthusiasm as evidence of demand.
How does this connect to your AI transformation work?
Discovery helps establish whether AI has a useful role, which outcome matters and what constraints the delivery team must respect. My AI transformation work carries that understanding into program decisions, agent development and organizational change. Some discovery engagements will justify a simpler improvement that needs no AI.
Related foundations: The Design Council’s Framework for Innovation describes broad investigation followed by a clearer definition of the challenge, with learning that can send a team back to revisit its assumptions. ASQ’s Five Whys guidance addresses questioning beneath symptoms. These are established methods; the discussion, scenarios and illustrative brief here present how I would apply investigative judgment in a business engagement.