How would you choose the first working slice of a customer deployment and decide what it proves?

Instruction: Select a working path through the relevant systems that tests the riskiest assumption. Distinguish observed evidence from what a prototype cannot yet prove.

Context: Makes the first slice an experiment in customer-system compatibility and workflow correctness, with clear evidence for the next investment.

Updated

Example Answer

I'd build the slice that tests the assumption most likely to break the deployment. For a hypothetical dispatch assistant, that might be whether the customer API exposes reliable inventory freshness. I'd read one order, fetch availability, show its source and update or version evidence, and produce a proposal for an operator to inspect. Retrieval time would be recorded separately; unknown freshness would stay unknown.

Before building, I'd agree the test cases, expected output and result that would change the design. I'd keep this first path read-only and record missing or inconsistent responses. A successful experiment would justify the next step. It would not prove every warehouse, exception, permission or production failure path works.

Make it your own

Choose the uncertainty that genuinely determines viability in your example. Explain why a mock cannot resolve it and how the smallest approved integration can.

Why this works

The slice proves a specific customer-dependent assumption and produces a decision, rather than treating a proof of concept as an abbreviated feature list. This is an original experiment grounded in the role's iterative delivery work.

Interviewer follow-up

What if the riskiest dependency is unavailable until the final week?

I'd build the adapter against an agreed contract and ask the customer team for approved evidence that reduces the uncertainty, such as schema examples or a test they can run. I'd still mark the actual integration check as unresolved. I'd reserve time to test it when access arrives and offer a narrower demonstration if the remaining evidence cannot support deployment.

Assessment criteria

These are practice criteria for this scenario, not an employer's scoring rubric.

  • Strong: Chooses a slice around a falsifiable customer dependency and distinguishes retrieval time from source freshness.
  • Adequate: Builds a small end-to-end path and states what it does not prove.
  • Weak: Selects only easy UI work or declares production readiness from one successful case.

A tempting weak answer

"I'd finish the interface first so the customer can see progress."

Why it fails: Visible progress may leave the dependency that can invalidate the whole design untested.

References

Related Questions