DISCOVERY / B2B / EVIDENCE
What to find out before the first line of code
Unknowns that can change the decision to build: a real customer episode, B2B buying roles, data access and the terms of a first pilot.
The team has an idea: a service that prepares a supplier proposal in minutes. The stack, sign-up form and screen list are already chosen. One uncomfortable question remains: who needs the result, and what must happen for them to start paying for it?
Before the first line of code, you do not need to know everything about the market. Find the unknowns that could change the decision to build itself. A few precise checks may substantially narrow the product. Sometimes the technology is simple, while data access or procurement is the real obstacle.
Define the decision your research should inform
“Do discovery” is too broad. State the choice: launch a standalone product, choose a first-version scenario, take on custom development or start with a limited service.
For a hypothetical procurement service: “Do we have grounds to invest one team-month in automating quotation comparison for small manufacturers?” Now the information needed is clear: comparison frequency, time-consuming steps, who uses and pays for the result, and what makes it acceptable.
State your own team’s constraints separately. If you cannot support dozens of document formats, that boundary should inform segment selection from the start. Otherwise, research may uncover attractive demand for a product the company cannot yet service.
Examine the most recent real episode
Ask the buyer to show a recent example: original quotations, their comparison sheet and the final decision. Agree on access and removal of confidential data before reviewing documents. The useful artefact is an anonymised structure of the task, not someone else’s commercial information.
Reconstruct the sequence: why the purchase arose, which options were found, what needed clarification, who checked terms and where delay occurred. Anchoring the discussion to one completed episode separates a familiar process story from what actually happened.
If someone says “comparison takes ages”, ask where the time went. Arithmetic may take ten minutes while a missing delivery date takes three days to obtain. Automated calculation would not remove that constraint.
User, buyer and approver may be different people
In AJTBD’s B2B analysis roles, internal approvals and implementation barriers are considered. A daily user’s approval does not mean the purchase will pass through every other link.
A simple map helps here. The buyer prepares the comparison. The production manager checks material suitability. The finance director approves spending. IT determines which documents may go to an external service. Each participant has a separate condition for agreement.
Meeting everyone before any prototype is not always possible. But an unknown participant should remain a visible risk. “The buyer liked it” does not answer who will authorise using the service with work data.
Separate knowledge into three columns
| What we know | What we assume | How to test it |
|---|---|---|
| Four quotations were compared in the last purchase | This happens every week | Review several cycles and the procurement log |
| Some terms were clarified by phone | Most information can be extracted automatically | Test an authorised sample of documents |
| The user is willing to give feedback | The company will pay for a pilot | Discuss a specific scope, price and approval process |
This table prevents evidence from quietly being promoted beyond its scope. One story is not market frequency. Willingness to talk is not a budget. Successfully analysing one file does not establish quality across every incoming format.
The next test should be small enough to stop without regret and meaningful enough to change the plan. A technical risk may call for processing a document sample with manual verification. Value may call for a manually prepared comparison used in a real purchasing decision.
Agree on pilot terms before starting
Specify inputs, the promised result, timing, manual-work boundaries and acceptance criteria. For example, the buyer must receive comparable terms in specified fields, with every value linked to its source document. This is more concrete than “AI automates procurement” and gives engineers a clear requirement for traceability.
Decide in advance which results would change the plan. If most work involves missing information, you may need a service that collects answers. If data cannot leave the company, deployment must change. If savings are too small for the price, revisit the scenario or pricing model.
What to hand over to engineering
By the first version, the chosen user, trigger situation, useful outcome, constraints, available evidence and remaining risks should be clear. Add a way to observe post-release behaviour and a person responsible for the decision after the pilot.
Uncertainty remains, but it is now explicit and tied to actions. The team has a reason to build exactly the part of the system needed for the next testable result.
