Find the constraints that can invalidate the pilot before building it

TL;DR: Test the constraints that could invalidate the proposed workflow before spending on dependent work. Keep multiple risks visible: access, ownership, security, cost and the success definition can interact, and none has to be the single cause of failure.

Where you are. You have a record of the customer's request and the commitments made on the call. Now turn the unresolved questions into a short sequence of feasibility checks.

Find the decision before ranking the risk

A missing credential is not necessarily a blocker. It becomes one when no approved path can provide the required data before the work that depends on it. A weekly refresh may be enough for a planning report and useless for a fifteen-minute exception workflow. Describe the required behavior first, then test whether the available path can deliver it.

Some constraints are knowable early; others emerge when requirements or environments change. The purpose of discovery is to reduce preventable uncertainty, not to promise that week one can reveal every future problem. Record the evidence date so a later change can be distinguished from a question nobody asked.

A premortem is one way to generate candidates. Gary Klein's project-premortem method asks participants to imagine failure and identify plausible causes. Collect those possibilities independently, then turn them into checks. They are hypotheses, not findings. The AHRQ premortem tool similarly moves from imagined failure reasons to mitigation planning.

The five categories below are a starting list for this course, not measured shares of failed engagements.

Five constraints to test

Usable data access. Does the required information exist, and can the intended service read it at the necessary freshness? Ask for a sample through the proposed route, with timestamps and the fields the workflow actually needs. A manual export in an email does not establish recurring service access. If the data does not exist, distinguish collecting it from merely granting a credential.

There is a documented example of how this can consume a pilot. In Reflections on Palantir (2024), Nabeel Qureshi describes pilots whose time was consumed by data-access negotiations, leaving a rushed demonstration at the end. That is his account of particular experiences, not a frequency estimate for this course. The practical response is to make an access check an early dependency with an explicit decision date.

Operating ownership. Identify who uses the result, who can change the process and who handles an unresolved case. A buyer may own the budget while another team owns the queue. If those responsibilities are split, schedule the joint decision; do not assume the buyer can commit the other team's working hours.

Security and approval constraints. Obtain the relevant policy and named reviewer. “Nothing has ever been approved” and “this design is forbidden” are different statements. Confirm the data class, permitted processing location and outbound-call rules. A VPC is not a universal answer: an external model call can still move data outside the allowed boundary even if the application runs in a private subnet.

Unit economics. Define value per completed unit and the allowable total cost before choosing an expensive path. Include retries, review and allocated infrastructure where relevant. Time released for other work is not automatically cash saved, and a buyer's estimate needs a measurement plan.

An agreed decision rule. Stakeholders can care about different outcomes without making the project impossible. Write the primary outcome and the constraints that must also hold. For example, faster shipment identification can be the outcome, while no unauthorized refunds and an affordable review queue are requirements. Ask the decision owner how conflicting results will be resolved.

Calculate the cost ceiling without hiding the assumptions

This synthetic planning envelope is separate from later course budgets. Assume 100,000 completed units a day, a value estimate of 2 cents per completed unit, and a buyer-selected maximum tool cost of 20% of that value. Assume all units complete for this first calculation; failure and retry costs would have to be added to a real ledger.

These are invented exercise prices, not current vendor prices. Design B fits the supplied machine-cost budget with 150 dollars/day remaining for other costs. That is not proof it fits the total budget or meets quality requirements. The claim that rules settle 95% of work still needs evidence.

Change the escalation share to 20%: machine cost becomes 100 dollars + 600 dollars = 700 dollars/day, exceeding the 400 dollars budget before review. If every other cost were zero, the break-even escalation share would be 10%, because 0.1 + share × 3 = 0.4 cents per unit. Any additional costs lower that allowable share. This is the question to settle before a prototype makes the costly path feel inevitable.

Request evidence that can change the plan

For the freight pilot, use this synthetic constraint register to select the next checks:

Prioritize the checks that could invalidate the next expensive step. A one-hour access test may be worth doing before a week of model tuning. Do not assign invented probabilities to make the register look quantitative. Use observed evidence, a clear impact and a dated check; record uncertainty where no estimate is defensible.

Inspect previous attempts without assuming the cause persists

Ask whether someone already tried to solve the workflow, then request the repository, incident review or decision record. Distinguish an old technical limitation from a still-active restriction. A rejected external service may say little about a locally hosted design. A failed identity mapping with the same source data is more directly relevant.

Interview the operator and the previous implementer where possible. Their accounts can disagree without either being dishonest: one remembers a working demo, the other remembers the cases it excluded. Reconstruct the claim using an example and an observable failure, not the confidence of the narrator.

Report the unresolved decision

State what constraint matters, what evidence would resolve it, who owns that decision and what you recommend if it remains unresolved. A narrower historical pilot may still be worth funding, provided its question has value on its own. Do not label it mitigation if it removes the very capability the buyer needs to decide on.

If no permitted alternative meets the requirement, recommend stopping this scope. Inventing a fallback to soften the message creates another unsupported promise. The decision record should make both the limitation and the cost already incurred visible.

The spine below runs the five categories in order and ends where the register does: an ordering by what each check can invalidate, not by how worrying it sounds.

Do this before moving on

Take the supplied constraint register and choose the first two checks for a two-week historical lookup demonstration. Explain which planned work each check unlocks. Then change the buyer's condition: no funding unless the pilot proves live fifteen-minute handling. Decide whether the daily-export fallback still answers the funded question.

Also recompute Design B for a 20% escalation rate and name two costs missing from the envelope.

Worked review. Verify usable exports and identifier reconciliation before building the lookup path; confirm operator time in parallel because the evaluation depends on it. A historical-only fallback does not prove live handling. Obtain an approved fresh path or renegotiate/stop that scope. At 20% escalation the stated machine cost is 700 dollars/day, already over budget. Human review, retries and allocated infrastructure are examples of additional costs; they cannot rescue the deficit.

Go deeper

• Scoping ambiguous problems is where the narrower alternative comes from when a blocker holds.
• AI cost and unit economics extends the envelope to a complete workflow cost ledger.
• VPC deployment explains the topology and its remaining access and egress responsibilities.
• Stakeholder management is how you get a real answer about who has said no before.
• Reading systems is the method for the half hour you spend with the dead project's code.

Key takeaways

• A constraint is a blocker relative to a specific workflow, date and approval boundary.
• Use access, ownership, security, cost and success criteria as prompts; keep interacting risks visible.
• Treat premortem ideas and previous-project stories as hypotheses to verify.
• A cheaper route needs measured coverage and total-cost accounting, not just a claimed escalation percentage.
• A fallback must answer a worthwhile agreed question; otherwise recommend changing or stopping the scope.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1Why is 'does the data exist' insufficient?

   Answer it, then reveal

2. 2With 0.1 cents per unit for rules and model calls costing 3 cents on 20% of 100,000 daily units, what is machine cost?

   250 dollars/day400 dollars/day700 dollars/day

3. 3The buyer funds only proof of live fifteen-minute handling, but daily exports are the only approved path. Is a historical demo an equivalent fallback?

   Yes, if the demo looks convincingNo; it tests a different question and needs a revised agreementYes, because historical records are real data