Worked questionsSkill 02: Build to learn, not just to show
Which prototype would you build first?
Three prototypes, three different questions. Pick the one that tests your riskiest assumption, and say what would make you stop.
The question
RelayDesk, a fictional support workspace, is about to commit four engineer-weeks. The team suspects tickets stall because nobody knows who owns the answer, not because replies are slow to write. You can try one of three things first.
- 1 hour
- A clickable mock of a routing screen.
- 1 day
- A manual concierge test: a person routes real-looking tickets to owners by hand.
- 3 days
- An autonomous-reply demo that drafts and sends answers.
Invented effort assumptions for comparison, not benchmarks. Any concierge test uses approved synthetic or redacted tickets and takes no unsupervised customer-facing action.
“Before committing four engineer-weeks, how would you test whether unclear ticket ownership, not writing speed, is the real obstacle?”
Your turn
Say your answer out loud, or jot notes below. Both work. Or skip to the worked answer.
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Name the riskiest assumption
“We believe finding an owner, not composing an answer, is what holds tickets up. I want to test whether clearer ownership changes the workflow.”
Why it works: It stops a flashy prototype standing in for useful learning.
Step 2: Compare what each method tests
“The mock tests whether people understand the routing screen. The concierge test tests the process on realistic work. The auto-reply demo mostly tests a different capability.”
Why it works: The method follows the uncertainty, not the technology.
Step 3: Choose and bound the experiment
“I’d start with a concierge test with agents and a lead on a small approved packet, recording how long owner assignment takes and why it fails. I’d add the mock if the routing screen itself is unclear.”
Why it works: A defensible first test that doesn’t pretend to prove lift or scale. Another choice is fine if it targets a different, clearly stated uncertainty.
Step 4: Say what would make you continue or stop
“I’d continue only if the test shows a repeatable ownership obstacle we can remove without just moving the work or adding errors. If policy or permissions dominate, I’d stop and reframe. Even a good result leaves integration, security, reliability and rollout work.”
Why it works: It ends with a learning decision and keeps a demo separate from launch readiness.
The answer, in short
- Decision
- Run the one-day concierge routing test first; add the mock only if the routing screen is the open question.
- Because
- It is the only option that tests the ownership assumption on realistic work. The auto-reply demo tests writing, the thing we doubt matters most.
- What would change it
- If the test shows policy or permissions, not ownership, cause most waits, reframe before spending the four weeks.
Common traps
- Demo theatre: building the impressive thing instead of the informative one.
- Building before stating the question.
- Treating low cost as low risk.
- Calling a prototype production-ready.
Check your answer
- Did I name what the prototype should teach?
- Did I explain why this method fits that question?
- Did I state what would make me continue or stop?
- Did I separate prototype evidence from launch readiness?
Want to practise explaining this decision aloud? Try an AI coach on Socratify.
Last reviewed Nov 9, 2026