Prompt and context
A B2B SaaS company has 1,200 customers and 85,000 weekly active users. Customer success, support operations, and account managers all say they need “an internal tool to improve efficiency,” but they describe no shared problem. You have 2 weeks for discovery and one engineering squad for 6 weeks of implementation. The tool should reuse the existing CRM and ticketing system; you cannot add headcount or rebuild a platform.
Explain what you would ask, how you would identify the real workflow problem, which users you would serve first, how you would define an MVP and success metrics, and when you would continue, change direction, or stop.
What the interviewer is testing
- Whether you can decompose a vague request into users, tasks, frequency, pain, and business outcomes.
- Whether you use evidence to validate the problem instead of accepting “build a tool” as the solution.
- Whether you can scope a deliverable MVP within 2 weeks of discovery and 6 weeks of engineering.
- Whether you can handle conflicting team goals and integration boundaries.
- Whether you use segmented metrics and stop rules instead of reporting launch or satisfaction alone.
Questions to clarify first
- What does “efficiency” mean here: handling time, duplicate entry, error rate, response wait, or switching between systems?
- Which role encounters the issue most often, and what are its frequency and consequences?
- How does the current workflow run, and which steps move between the CRM, ticketing system, and spreadsheets?
- Does the issue affect revenue, retention, compliance, or only employee convenience?
- How many users and real activity records can you reach in 2 weeks, and which data may you inspect?
- Must the 6-week outcome be a usable workflow, or can it be an interactive prototype plus human service?
30-second answer framework
I would translate “efficiency” into an observable task, then prioritize by role, frequency, and impact. During two weeks of discovery, I would combine interviews, workflow observation, ticket data, and CRM data to verify who loses what in which context. The MVP would solve one high-frequency, measurable workflow, reuse existing system interfaces, and keep a human fallback. Metrics would cover task completion time, duplicate entry, error rate, adoption, and user outcomes, with rules defined in advance for continuing, changing, or stopping investment.
Step-by-step deep dive
Step 1: Rewrite the request as problem hypotheses
Rewrite “we need an internal tool” as “a role experiences a friction in a task that worsens a result.” An account manager might copy information between the CRM and ticketing system; support operations might care more about assignment delay. Write several hypotheses and do not treat an implementation form as the problem.
Step 2: Plan discovery by evidence strength
Observe real workflows and recent cases first, use semi-structured interviews to explain causes, and then use logs, tickets, and CRM data to estimate scale. A stated preference is a lead, not proof of demand. For each hypothesis, record supporting evidence, counterexamples, open questions, and the next validation step.
Step 3: Choose target users and priority
Rank workflows by frequency, impact, reachability, and feasibility of improvement. Prioritize a frequent workflow with a clear impact that can improve within existing system boundaries. A rare but high-risk workflow needs a separate security or compliance assessment; do not discard it just because the user count is small.
Step 4: Scope a six-week MVP
The MVP should cover one end-to-end task, such as reading customer context from a ticket, producing a structured handling draft, and writing it back to the CRM after employee confirmation. Do not add a new permission center, full reporting suite, or cross-team platform yet. If an integration fails, preserve the original path and let employees view, edit, and undo the result.
Step 5: Handle team conflict and integration limits
Have teams discuss the same workflow map and metric tree instead of comparing feature lists. Confirm permissions, write rules, rate limits, and retention boundaries for the CRM and ticketing system. Anything that cannot be safely integrated within six weeks becomes an export, human confirmation, or later scope.
Step 6: Define metrics and stop rules
Leading indicators include target-workflow adoption, completion time, and duplicate entry. Outcome indicators include error rate, customer response time, and rework. Guardrails include permission errors, data-leak incidents, employee complaints, and system failure rate. If adoption rises while errors or rework exceed a threshold, pause expansion and return to problem validation.
Step 7: Plan validation and rollout
Validate the flow with a prototype and human simulation, then pilot one team and one task type. Set a baseline, a control, or a before-and-after comparison, and segment results by role and task. Review evidence weekly to decide whether to expand, revise the hypothesis, continue human service, or stop the project.
High-quality sample answer
I would not accept “build a tool” as the problem statement. I would break efficiency into concrete tasks, identify which role is duplicating entry, waiting, or making errors, and use two weeks of observation, interviews, CRM data, and ticket data to verify scale. I would rank options by frequency, impact, reachability, and six-week feasibility, then choose one high-frequency workflow with a measurable outcome. The MVP would read context from existing systems, produce an editable draft, and write back only after employee confirmation; the original workflow would remain available when permissions or writes fail. Metrics would include adoption, completion time, duplicate entry, error rate, rework, and customer response time, with permission errors, data leaks, and system failures as guardrails. I would pilot with one team, predefine expansion, change, and stop thresholds, and pause expansion if efficiency improves alongside rising errors or rework.
Common mistakes
- Treating “internal tool” as the requirement and jumping to screens or features.
- Interviewing only managers instead of observing frontline work.
- Replacing behavioral evidence and outcome metrics with one satisfaction survey.
- Serving three teams at once and completing no end-to-end flow in six weeks.
- Ignoring CRM and ticketing permissions, writes, and retention limits.
- Tracking adoption without error, rework, and privacy guardrails.
- Having no stop rule and using prior investment as the reason to continue.
Follow-up questions and responses
What if all three teams say their problem is the most important?
Ask each team for cases using the same frequency, impact, evidence, and feasibility criteria. Prioritize verifiable outcomes and the ability to complete a six-week loop; record the rest as later hypotheses instead of replacing prioritization with political influence.
What if the business insists on delivering the whole platform at once?
Separate shared constraints from the first workflow. Deliver one reversible, observable vertical slice, prove value with real metrics, and then decide which interfaces and permissions deserve platform investment. Do not commit scope that cannot be safely validated within six weeks.
What if MVP adoption is low although interviews are positive?
Review actual task paths, trigger timing, write permissions, and failure logs, distinguishing awareness from use in work. Check whether confirmation cost or workflow disruption is the blocker; run a small experiment after reducing the friction rather than hiding the behavioral gap with more promotion.
What if efficiency improves but error rate also rises?
Segment by role, task, and error severity, and pause expansion in high-risk contexts. If errors exceed the guardrail, restore human confirmation, narrow scope, or change the flow. Continue investment only when errors are acceptable and outcome metrics keep improving.