Chapter 6: Discover the Real Problem

The press release on the table

Tunde Bakare puts a competitor’s press release on the conference table. “KwikPay has card acceptance live in two markets,” he says. “The merchants are asking us for it. Two asked me directly at the trader association meeting. We need to ship card acceptance by the end of the quarter.”

Amara Diallo, head of product, reads the release twice. “Before we ship anything, I would like to know what ‘it’ is. KwikPay’s release says merchants can take card payments in the store. That is not a problem statement. It is a solution announcement.”

“What is there to discover?” Tunde says. “The customers said what they want.”

“Then my question is simple. Tell me about the last time a merchant lost a sale because she could not take a card. How often does it happen, at what ticket size, and what does it cost her compared with everything else that interrupts her cash? If the answer is small, we would be building a feature to cure a symptom while the disease sits two doors down.”

This is the discipline of discovery: the work between a request and a commitment, finding out whether the request is a problem, a symptom, or a solution someone fell in love with. It separates leaders who build the right thing from leaders who build the requested thing, because most projects do not die of bad execution. They die of a well-executed answer to the wrong question.

A request is a hypothesis wearing a solution’s clothes

Every request that arrives in a project office is already a conclusion. Someone looked at a situation, decided what was wrong, and chose the fix they are asking you to build. The request is the last step of their reasoning, not the first. When Tunde says “ship card acceptance,” he is compressing a chain of claims: merchants are losing sales; the loss is caused by missing card acceptance; card acceptance can be delivered legally and profitably; no better response would cost less and help more. None of those claims has been tested. The request is a hypothesis wearing a solution’s clothes.

The first task of discovery is to unpack that chain and separate five things ordinary conversation keeps tangled.

A symptom is the visible sign of trouble: the customer walking next door, the call-center complaint, the queue past lunch. Symptoms are real and what people mention first, but they are almost never the thing to build against: the same symptom can come from different causes.

A cause is the mechanism producing the symptom: settlement arriving three days late, a checkout asking for five fields, a stock gap on the items the card-carrying customer came for. Causes sit one level below symptoms, and usually below where people are looking.

A need is a gap between the state a stakeholder lives in and the state they want, stated without a solution attached. The merchant needs money to arrive at a predictable time and to see what arrived without spending Sunday night reconciling. Needs are the language of the problem statement, deliberately solution-free.

An opportunity is a need the organization can serve at a profit, within its capability and obligations. KijaniPay’s discovery ends not with “merchants need card acceptance” but with “small merchants need settlement they can predict and cash-flow visibility they can act on, and KijaniPay can serve that with its existing rails and compliance.” The card request turns out to be one small feature inside that sentence.

A constraint is not a need; it is the condition the answer must satisfy. For KijaniPay the binding constraint is fraud and money-laundering control: instant settlement, the first thing merchants will ask for, is exactly what compliance cannot approve in a high-fraud market. Discovery must hear the constraint, because it changes what “predictable” means: settled at a guaranteed time with a risk-scored hold, not instantly for everyone.

Keep these apart on paper before they blur in the room. The cheapest instrument is a habit: when someone states a problem, ask which of the five they just spoke. “We need card acceptance” is a solution; “we are losing sales” is a symptom; “merchants cannot predict when money arrives” is a need; “we can serve that need within our compliance constraints” is an opportunity. People who can make these distinctions in conversation have usually done the discovery work; the rest are about to skip it.

Write the problem before you name the solution

The practical instrument of this distinction is the problem statement, a short written sentence the team can check like a contract. It has a strict rule: it may describe who is affected, the current state, the desired state, the evidence that the gap is real, and why closing it matters, and it may not contain any solution vocabulary. No “build,” no “app,” no “button,” no “automate,” no product name. If the statement contains a solution, the sentence is a specification wearing a problem statement’s clothes, and everyone downstream will treat it as decided.

Weak: “We need a mobile app so patients can book appointments without calling the front desk.”

The solution is the first five words. The sentence settles the build before the problem is named, and the discovery conversation is over.

Strong: “Patients who work during clinic hours cannot reliably reach the front desk to book, so they skip appointments or walk in late; this costs the clinic lost visits and the patients lost care, and the evidence is the call log showing 41 percent of booking calls abandoned and a 12 percent no-show gap between phone-booked and walk-in visits.”

No app appears. The sentence names who, the current state, the desired state, the evidence, and why it matters, and the answer stays genuinely open: an app, an online form, a callback promise, longer desk hours, a booking window at a partner pharmacy. The problem statement exists so the solution has to earn its way in.

The classic climb from request to sentence is the five whys, the repeated-why question associated with Toyota’s production system. Keep asking why until the answer stops being about the requested object and starts being about the stakeholder. “Why card acceptance? Because we are losing sales. Why? Because customers pay by card elsewhere. Why does that matter now? Because settlement is unpredictable and the merchant borrows every Monday.” The climb works, with one caution: it tunnels. Repeated why questions tend to produce one clean cause chain and silence the others, and a single chain is usually a half-truth. The five whys is a ladder out of the symptom; the evidence work below is the guard against trusting the ladder.

The evidence ladder

A problem statement is a claim, and claims sit on rungs of evidence. The ladder is the chapter’s mental model and the reference every later artifact inherits.

Figure 6.1: The evidence ladder. Each rung holds a different kind
of claim, and a decision is only as strong as the rung its
evidence actually sits on.

  VALIDATED OUTCOME      measured result of a real change in a
                         real context, repeated over time
  MEASURED BEHAVIOR      actions counted across many people or
                         transactions, with dates and volumes
  OBSERVATION            what people actually do, seen directly
                         or in the traces they leave behind
  ANECDOTE               one person's account of one event
  OPINION                what someone believes to be true

  CLIMB:  claim -> probe -> evidence -> decision
  every climb costs time and money, so climb only when a
  decision depends on the rung.

Opinion is the ground floor, and it includes what senior people believe. Anecdote is one rung up: one person’s account of a real event, valuable for direction and worthless for size. Observation is where evidence earns the name — behavior seen directly or read from traces, like the call log in the problem statement — and measured behavior counts it across volume and time: “41 percent of calls abandoned” is measured behavior; “people struggle to get through” is anecdote. Validated outcome is the top rung: a real change in a real context, measured afterward and repeated enough that luck is unlikely, the rung pilots live on.

Three rules govern the ladder. First, never claim a higher rung than you reached; “we know merchants want this” is a claim that needs measured behavior, not a focus group. Second, climb only when the decision depends on the rung; a low-stakes choice can ride on an anecdote, while a decision that commits other people’s work needs measured behavior at minimum. Third, climb one rung at a time: a full pilot is not the answer to a question the observation rung could have settled.

The ladder also explains why discovery conversations go wrong. When Tunde says the merchants asked him, he is citing anecdote and treating it as measured behavior. The argument is not whether the merchants said it; it is what the saying proves.

Ask about last week, not next month

Discovery begins in the field, and its oldest tools are its most reliable: watching people work and asking what they have already done.

Interviews sound like the easy one and are the easiest to do badly. The bad interview asks hypotheticals: “Would you use an app for this?” “How much would you value same-day settlement?” The polite answer is always yes, because the merchant does not want to disappoint the person asking, and because the question demands a prediction about a product she has never seen. A market of phantom demand is built entirely from polite yeses. The good interview asks about the past, because the past happened and can be checked. The reliable forms are “Tell me about the last time…”, “What did you do then?”, “What did it cost you?”, and “What did you say to yourself?” The interviewer’s silence is a tool; after an answer, a beat of silence produces the real answer, the one about Sunday night reconciliation, because people confess what matters when they sense the interviewer is listening.

An interview is a conversation with one purpose: to collect the interviewee’s sequence of events in their own words. The guide should contain openings, not checklists, and it deserves a check for three telltale leading patterns: the hypothetical (“would you”), the compound (“do you struggle with reconciliation and late settlement?”), and the approval-seeking (“would it help if we…?”). An interview whose every question contains the answer is not discovery; it is testimonial collection.

Here is that craft in the KijaniPay field work. Amara sits with Amina, a fabric trader who takes most payments as mobile money.

“You asked us for card acceptance,” Amara says. “Before I add anything to your counter, tell me about the last time a customer could not pay.”

“Last Saturday,” Amina says. “A woman with a large order. She had a card, no cash. She went next door. That happens maybe twice a month. The small ones, they just leave. Altogether, a few hundred units a month.”

“A few hundred units?”

“Small money. The settlement is the money.”

“And what else happened that Saturday?”

Amina looks at her hands. “I counted the receipts at midnight. I had made sixty-two thousand and owed the supplier sixty thousand by Monday. I borrowed. I borrow every Monday, from Mama Kumba, ten percent a week, because the settlement takes two days, and sometimes longer, and I cannot wait for money that might not come.”

“Every Monday?”

“Every Monday. For a year.”

That is the moment the project changed. The card request was real and small: a few hundred units a month, four figures a year. The settlement problem was large and structural: a weekly borrow at ten percent, about 312,000 units a year. Amara did not discover this by asking better product questions. She discovered it by asking about last week instead of next month, and letting Amina take the conversation to the midnight count.

Watch the counter, not the survey

Observation is the second field tool, and it corrects the one thing interviews get wrong: what people say and what people do disagree, reliably, in the direction of self-flattery. Everyone believes they follow the checklist; nobody does. Contextual inquiry comes from design research: go where the behavior happens, when it happens, and watch the work with the person doing it, asking quiet questions as it unfolds. It is not shadowing for drama; it is watching for the friction the person has stopped noticing, the exact friction a product might remove.

The minimum viable form is small and disciplined: three to five sessions, in settings chosen for diversity, at the moments the work actually happens. For the merchants, that meant a Sunday night reconciliation and a Monday morning restock, not a Tuesday afternoon chat. The sessions turned up two findings the interviews missed. First, reconciliation was not a paperwork problem; it was a trust problem, because the platform’s statement listed transactions in a different order and format than the bank’s, so the merchant could not tell whether the platform had stolen from her or the bank had. Second, the merchants checked the bank’s numbers, not the platform’s, and the platform’s app sat unused while the paper passbook got the trust. No survey would have produced that.

Observation gets skipped because it feels slow, like watching instead of doing. The tell that an organization is faking it is the observation tour: a one-hour walkthrough with the branch manager, who shows the work as she wants it seen. It discovers nothing, because the tour is narrated, not observed. Real observation happens when the work is happening, and the observer writes notes in the field, in the words of the people observed, before the team reconvenes to let a pre-existing opinion organize the evidence.

The merchant’s week

The third tool is the journey map, and it is best kept deliberately small. A journey map is a time-ordered story of one episode from the stakeholder’s point of view, with actions, systems, emotions, and pain marked at each step. Not the two-meter epic of the entire life cycle: one episode, six to eight steps, drawn in an afternoon. For KijaniPay the episode chose itself: the merchant’s week from sales to restock.

Monday: borrow sixty thousand from the informal lender at ten percent weekly, because the money to restock has not arrived. Thursday: the settlement lands, two days late, proving the borrow necessary. Friday: repay, plus six thousand. Saturday: the big sales day, and the day the card-carrying customer walks. Sunday night: count receipts against the bank statement, hours of matching, then decide, again, whether to borrow.

The pain does not live where the team thought. It lives at the Monday borrow and the Sunday night count; the card request sits at Saturday, small and occasional. The journey map argued with no one; it placed the request on a week where two larger pains surrounded it.

The fourth tool is the data, and here the arithmetic becomes the argument. The settlement records show a median of two days from sale to settlement, with a tail: one in ten takes six days or more, concentrated in the market with the weakest banking partner. Now the numbers that matter:

• Amina’s daily takings run about forty thousand units, across twenty-five selling days: about one million a month, twelve million a year.
• Her margin is roughly fifteen percent, so annual profit is about 1.8 million units.
• She borrows sixty thousand units every Monday at ten percent weekly: six thousand a week, about 312,000 units a year.
• 312,000 divided by 1.8 million is about 17 percent: the settlement lag consumes roughly one unit of profit in six before anything else goes wrong.

The sensitivity is worth stating: at five percent weekly instead of ten, the cost halves; in the tail weeks she misses restock entirely and it is worse. The rate does not carry the argument; the structure does, because no feature that saves a few hundred units a month can compete with a fix that removes a 312,000-unit annual cost. The map located the pain; the data priced it; the price tag moved the decision from feature to platform promise.

One more data point comes from the compliance lens the project inherited from its selection. The constraint sharpened the promise: not “settle instantly” but “settle at a guaranteed time, next morning in compliant markets, with holds that depend on transaction risk.” Predictable, not instant — the difference between a product compliance can approve and one it will rightly stop. The distinction returns in later chapters, when the platform executes and settlement reconciliation is tested under real volume.

The assumption backlog and the probes that kill

Everything the team now believes is still a claim, and the claims that matter are the ones that would kill the project if false. The working instrument is the assumption backlog: a short, owned list of the propositions the decision rests on, each with the rung its evidence sits on, the test that would settle it, and the consequence if it fails. Its rule paraphrases the ladder: for every assumption, say which rung the current evidence occupies, and do not let an assumption sit below the rung the decision needs.

The minimum viable assumption backlog for KijaniPay’s discovery fits on one page.

Five rows, one page, each with a named test and an owner. The table does not replace judgment; it focuses it. Two rows carry the decision — settlement timing unpredictable, the cost material — and both sit on measured behavior. Trust sits on anecdote and needs the cheapest probe that will move it up, a prototype; compliance sits on opinion and will not be settled until a pilot. The backlog is honest about what the project knows and what it is choosing to find out later, and that honesty is the difference between discovery and theater.

The probes form a small ladder of their own. A prototype is a cheap, fake version of the experience, used to test desirability and usability: the merchants do not need working rails to react to a printed statement saying “settles tomorrow morning by 08:00.” A spike is a bounded technical test that retires a feasibility question without building product: can the settlement engine hit the bank’s cutoff? A pilot is a real offer, to real merchants, with real money, at small volume, testing the validated-outcome rung: does the promise hold, do merchants change behavior, does fraud loss stay inside the model? A feasibility study is the whole proposition under constraint, the form discovery takes in predictive work. The rule for choosing is the ladder rule: use the cheapest probe that can reach the rung the next decision needs. Do not run a pilot to answer a question a prototype could answer in a week, and do not trust a prototype to answer a question only real money can answer.

The Tuesday recommendation

Six weeks after the press release, Amara brings the discovery to the leadership meeting, and the shape of the meeting is the shape of the discovery: the problem statement first, the evidence under it, the recommendation after the evidence.

The problem statement, in one sentence: small merchants across the three markets cannot predict when settlement money arrives or verify what arrived, so they borrow at high cost every week and distrust the platform’s numbers; KijaniPay can remove that cost with the rails it operates, inside the compliance constraints it accepts. The evidence sits on two rungs: measured behavior from the settlement data and the ledger arithmetic, and direct observation from the Sunday night sessions. The request that started the project, card acceptance, appears in the evidence trail as a real but small pain, with its own row in the recommendation: an experiment, not a build.

The recommendation has three parts, and the first increment is predictable settlement: a guaranteed next-morning settlement window in the compliant market, risk-scored holds explained in the statement, and a daily statement in the format the bank already uses, so Sunday night stops being an act of faith. Second, the working-capital offer becomes a pilot, because the settlement history the platform now holds is the credit evidence the informal lender never had: priced at a fraction of the ten percent weekly rate for merchants with clean histories, and killed if the loss rate exceeds the model. Third, card acceptance is deferred to an experiment with a written trigger: it returns when a prototype and merchant interviews show it is more than a rounding error against the settlement work, or when a card-dominated market demands it.

Tunde reads the recommendation. “So we are not shipping card acceptance.”

“We are not shipping card acceptance first,” Amara says. “We are shipping the thing that costs the merchants six figures a year. The thing that started this meeting costs them four figures a year. Both are real. One of them is a project.”

When discovery is enough

Discovery is a cost, and it has a stopping rule, the decision discipline the whole practice exists to serve. The question is never “have we discovered everything?” It is “have we reached the rung the next decision needs?” A project is ready to authorize when four conditions hold: the assumptions that would kill it have been tested at or above the rung the decision needs; the problem statement has survived contact with the field, rewritten after observation and numbers, not merely confirmed; the value hypothesis can be written with named evidence, owners, and a measured cost; and the uncertainty that remains is delivery uncertainty, learnable during execution, not problem uncertainty that should have been retired before commitment. When the four hold, further discovery is procrastination wearing a lab coat; when they do not, authorization is a bet the organization is making on purpose.

The value-of-information arithmetic behind the rule is simple. A probe is worth running only when its expected value exceeds its cost — when the answer could change the decision, and when being wrong costs more than running the probe. The card-acceptance prototype cost a week and could have changed the decision; it was worth running. A full pilot to answer whether merchants carry cards, when observation already answered it, would have been a month spent confirming a known answer. Stop when the next probe cannot plausibly change the recommendation, and be prepared to name the finding that would have changed it.

Two failure patterns guard the two ends of the discipline, and both look like competence from the inside. The first is the favorite solution: the organization that has already decided and runs discovery as confirmation. The interview guide leads the witness, the pilot runs in the friendliest site, the data pull starts with the conclusion and selects until it fits, and the person who returns with disconfirming evidence is asked to look again. Its tell is not the fakeness of individual steps, usually defensible in isolation; it is the absence of any finding that changed the plan. A discovery that never surprises the sponsor has discovered nothing. The second is the eternal discovery loop: the organization so afraid of committing that discovery becomes a career, producing one more study, one more workshop, one more “we need more data,” while the competitor ships and the need compounds. Its tell is the assumption backlog that never shrinks because no assumption is ever declared tested. Between them, the favorite solution spends the money on confirming and the loop spends it on never deciding. The discipline is not a point between the two; it is the stopping rule, applied with the same candor to the sponsor’s favorite idea as to everyone else’s.

What the delivery approach changes

The delivery approach changes where discovery lives, not whether it happens. In predictive delivery, discovery is a formal phase with a gate: the feasibility study, the options analysis, the business case review, the charter, and the gate must actually be able to reject, or it is a ceremony. In adaptive delivery, discovery and delivery interleave: every increment is an experiment, the assumption backlog is the working document, and “we shipped it” is a claim to be measured, not a goal to be celebrated. In hybrid delivery, the common case for KijaniPay, discovery is staged: a bounded discovery period produces the problem statement and the first increment, then delivery runs in tranches with evidence gates between them. What does not change across styles is the instrument set: the problem statement, the evidence ladder, the assumption backlog, the stopping rule. A method with no room for these is not a method; it is a schedule for building the favorite solution faster.

A word about the assistant that will draft your interview guides, cluster your field notes, and flag leading questions: a language model can do all three, usefully and fast. It can also produce a fluent summary of the merchant interviews that sounds like evidence and is not, because fluency is not measurement. The discipline has two rules for it. First, the model’s outputs are drafts until a human has read the raw material, and any finding that contradicts the recommendation is traced to its source before it enters the report. Second, merchant financial data, customer identifiers, and regulated or personal information stay out of any tool not approved for them. The model can help you see the field faster; it cannot stand at the counter, and the counter is where this project’s evidence came from.

Practice

1. A quick classification. Label each statement as symptom, cause, need, opportunity, or constraint: (a) “The front desk is overwhelmed at 8 a.m. because booking calls peak in the first hour.” (b) “Patients who work cannot reach the desk, and they need a way to book without waiting on hold.” (c) “We can serve that need with a callback service at lower cost than a new system.” (d) “Regulators require a licensed agent on any call that takes payment.” (e) “We are losing forty bookings a day.”

(a) contains a symptom and a cause: the overwhelm is the symptom, the call peak is one plausible cause, and the sentence needs evidence before the cause is accepted. (b) is the need, solution-free. (c) is an opportunity, and it names a solution (callback service); an opportunity can propose a direction, but it must be argued against alternatives. (d) is a constraint, a condition the answer must satisfy, not a problem to solve. (e) is a symptom, useful only with a source and time period attached, which is what moves it toward measured behavior.

2. The rewrite drill. Turn each request into a problem statement that passes the no-solution test: (a) “We need a mobile app for appointment booking.” (b) “The portal needs a better dashboard.” (c) “We should integrate with the accounting system.” Then state which of the five categories your final sentence sits in.

(a) “Working patients cannot reliably reach the desk to book, so they skip or walk in late; the call log shows 41 percent of booking calls abandoned.” (b) “Managers cannot see which clinics are short of capacity in time to act; they stitch three spreadsheets and discover shortages after the week.” (c) “Finance re-enters the same invoice data into two systems, costing about four hours of correction a week.” The test: if the sentence contains the solution (“app,” “dashboard,” “integrate”), delete it and write what changes for the stakeholder instead. Your final sentences should sit in the need category, with evidence attached.

3. Your assumption backlog. Take an initiative you know from work, community, or study, and write the five or six assumptions that would kill it if false. For each: the evidence rung it currently sits on, the cheapest probe that would move it up one rung, and the person accountable for running it. Then mark the two assumptions that most change the decision.

The exercise succeeds when the list contains at least one assumption the advocates would rather not write, because those are the ones that matter. The red flags are an all-opinion list with no probes, a list where every assumption is “known” with no evidence attached, and a probe list whose cheapest item still costs more than the decision it would improve. If you could not name an accountable owner, the backlog is decoration.

4. A decision room. Your discovery team has spent four weeks and the discovery budget is nearly spent. The sponsor wants a launch date. You have a problem statement with measured evidence for the pain, an anecdote-level trust hypothesis, and an untested feasibility question about a banking-partner cutoff that could make the entire offer impossible. You can afford exactly one more probe: a six-merchant prototype of the statement, or a two-week spike on the banking cutoff. Which do you run, and what do you tell the sponsor?

Run the spike on the banking cutoff. It is on the opinion rung with a binary answer that can kill the project; the prototype moves the trust hypothesis one rung, but the project dies on the cutoff regardless. This is the value-of-information rule in one decision: spend the money where the kill lives. Tell the sponsor the launch date is a function of the spike result: the spike answers in two weeks, and then the launch decision is real. The prototype is the unsafe choice, because it spends the last money confirming the likable part of the project. If capacity allows, run both, with the spike as the constraint; if only one can be funded, the spike is not close.

5. The mastery drill. A sponsor hands you a signed request: “We need a customer loyalty program with points and a mobile wallet, because our top competitor launched one.” Convert that predetermined solution request into three testable problem hypotheses, state the evidence each needs, and name the finding that would kill the project.

(1) Retention hypothesis: “Customers who defect do so because they lack an incentive to return, and the defection is large enough to fund a loyalty program.” Test: measure repeat-purchase gaps and the defection rate against the program’s cost; the claim needs measured behavior, not the competitor’s marketing. (2) Preference hypothesis: “The loyalty mechanism that drives retention for our customers is points or a wallet, rather than price, convenience, or stock availability.” Test: observation and a prototype with three mechanisms; the finding that kills the project is evidence that defection is driven by price or availability, which no points program fixes. (3) Economics hypothesis: “The program can be funded by the retained margin, with fraud and cost exposure bounded.” Test: arithmetic on the retention lift needed, then a pilot with real money and a kill threshold. The project dies if the retention lift required to pay for the program exceeds what any plausible mechanism can produce. The point is the discipline: the sponsor handed you a solution; you handed back problems with tests, and you made the kill criterion explicit before anyone spent a unit of the budget. An answer that merely rephrases the request into nicer versions of the loyalty program has failed the drill, however fluent it is.

6. Transfer question. What is the last request you were handed that was already a solution? What problem statement would it have produced, and what is the cheapest probe that would have tested the assumption underneath it?

Discovery is the discipline of un-solving the request: separating the symptom from the cause, the cause from the need, and the need from the opportunity, until the project stands on a problem that evidence supports instead of a solution that authority prefers. The most common next failure is not skipping discovery; it is finishing discovery and then writing the business case around the favorite solution, letting the gathered evidence become decoration for a decision already made. The case must be built from the problem and the tested assumptions, which is the subject of the next chapter, “Build a Business Case and Benefits Hypothesis.”

Notes

• KijaniPay is a composite case created for this book; no real company, merchant, market, or rate is depicted. The weekly informal rate of ten percent, the settlement lag distribution, and the ledgers are author-created teaching figures, and the arithmetic is provided so the reader can reproduce it. Informal weekly credit in the double digits exists in several markets; any real discovery must use the actual ledger.
• The five whys is associated with the Toyota Production System; see Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988). The caution that the technique can tunnel toward a single cause is the author’s.
• Contextual inquiry, observing users in the context of their work, comes from design research; see Hugh Beyer and Karen Holtzblatt, Contextual Design: Defining Customer-Centered Systems (Morgan Kaufmann, 1998), and Karen Holtzblatt, Jessamyn Burns Wendell, and Shelley Wood, Rapid Contextual Design (Morgan Kaufmann, 2005).
• The jobs-to-be-done idea, that people hire products to make progress on a job, is from Clayton M. Christensen and Michael E. Raynor, The Innovator’s Solution (Harvard Business School Press, 2003), and Clayton M. Christensen, Taddy Hall, Karen Dillon, and David S. Duncan, Competing Against Luck: The Story of Innovation and Customer Choice (HarperBusiness, 2016).
• Outcome-based need statements, and the warning against solution-framed requirements, are central to outcome-driven innovation; see Anthony W. Ulwick, What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services (McGraw-Hill, 2005).
• Customer development and the minimum viable product are from Steve Blank, The Four Steps to the Epiphany (K&S Ranch, 2013 edition), and Eric Ries, The Lean Startup (Crown Business, 2011), which popularized the build-measure-learn loop.
• The value-of-information stopping rule draws on decision analysis; see Howard Raiffa, Decision Analysis: Introductory Lectures on Choices under Uncertainty (Addison-Wesley, 1968).
• Confirmation bias, the preference for evidence that supports a favored conclusion, is documented in Raymond S. Nickerson, “Confirmation Bias: A Ubiquitous Phenomenon in Many Guises,” Review of General Psychology 2, no. 2 (1998): 175-220.
• ISO 21502:2020, the general ISO guidance on project management, treats opportunity identification and the development of a business case as the opening activities of a project life cycle; readers should consult the official publisher for the current edition. This book is independent of ISO, PMI, and all named framework owners.