FIELD · Handbook · 5 min read
Qualify the work before committing to the build
Separate an attractive opportunity from an executable customer engagement.
Arunank Sharan · Kuzushi Labs ·
In this article
A customer can have a valuable problem and still be unable to start a successful engagement. Qualification asks both whether the problem deserves investment and whether the people, access and decisions required to act are available. Its output is a decision and a bounded next step.
Write the opportunity in operational terms
Use this sentence: “For [population], improve [workflow outcome] from [baseline] toward [target], within [time and constraints], while preserving [critical conditions]. [Owner] will decide using [evidence].”
For a worked invoice workflow: “For 20,000 eligible invoices per month, reduce total staff handling from eight minutes per attempted invoice toward 4.8 minutes, including review and fallback, without applying an unapproved correction. The finance operations owner will decide after a four-week assisted pilot.” The volume and timings are assumptions to validate, not a commitment to achieve them.
Ask why the problem is urgent. A regulatory deadline, rising backlog, service-level failure and speculative innovation budget produce different scopes. Identify what happens if nothing changes for 90 days. Include process repair, better search, a rules engine and buying an existing product among the alternatives.
Inspect readiness without inventing a score
| Readiness area | Evidence to request | If missing |
|---|---|---|
| Sponsor | Named budget and scope decision maker, meeting cadence | Discovery only; do not imply authority from enthusiasm |
| Users | Access to representative operators and permission to observe work | Schedule observation before promising workflow impact |
| Domain ownership | Person who resolves disputed business definitions | Narrow to a definition that can be agreed |
| Data access | Approved sample, provenance and data-owner contact | Run an access task with a deadline |
| Technology ownership | Customer contact for identity, network and source APIs | Make integration discovery an explicit dependency |
| Funding | Discovery budget and route to production operating spend | Separate experiment funding from service ownership |
| Procurement | Purchase, security and supplier onboarding sequence | Put these on the delivery critical path |
| Operations | Named owner and support capacity after handover | Keep the work a bounded experiment |
“Unknown” creates a task, not a guessed rating. Assign every task an owner, due date, evidence and consequence. If a source owner cannot provide access by the agreed date, the choice is to reduce scope, move the milestone or stop; the team should not quietly substitute unrelated data and preserve the original promise.
Compare opportunities on a common basis
Suppose three candidate workflows are available. Use an explicit planning basis rather than general enthusiasm:
| Candidate | Monthly eligible tasks | Baseline minutes/task | Maximum baseline effort | Primary unresolved dependency |
|---|---|---|---|---|
| Invoice exceptions | 20,000 | 8 | 2,666.67 hours | Finance action permissions |
| Policy lookup | 12,000 | 6 | 1,200 hours | Source permissions and freshness |
| Contract intake | 1,000 | 25 | 416.67 hours | Counsel review and document rights |
These are ceilings on addressable baseline effort. They are not savings. A workflow with less apparent volume can be the better pilot if it provides faster evidence and avoids an unresolved critical dependency. Do not add these benefits if the same task appears in multiple workflows.
A useful ranking discussion compares expected net value, consequence of failure, access lead time, speed of learning, user pull and reuse potential. Record the rationale and uncertainty rather than multiplying arbitrary one-to-five ratings into a precise-looking result.
Separate the buying organization from the using organization
Map the economic buyer, sponsor, daily user, data owner, technical owner, security reviewer and service owner. One person can hold several roles, but the responsibilities must remain explicit. Ask who loses time during migration, who gains credit if adoption succeeds, and whose queue grows when automation escalates an exception.
Decision accountability in FIELD is informed by Bain’s work on decision roles. Our practical adaptation is a short record for each consequential choice: one decision owner, required agreements, people providing input, and an execution owner. A sponsor cannot waive another party’s legal right to data or an authority they do not possess.
Choose the next commercial step
Proceed to discovery when the problem is material, access is plausible and an owner can act. Offer a paid diagnostic when uncertainty is the main work. Commit to delivery only after the boundary, acceptance criteria and dependencies are sufficiently concrete. Decline or redirect when the requested outcome depends on unauthorized use, no accountable owner, an uneconomic baseline or an unsupported promise.
The qualification memo should fit on two pages: customer outcome, alternatives, readiness evidence, biggest uncertainty, first experiment, cost/time cap, decision date and stop condition. A meeting is complete when someone is accountable for that next decision.