Engineering input in a Jobs to be Done workshop

WHY THIS MATTERS Jobs to be Done reframes products around the progress users seek, helping teams avoid building features nobody needs. The question checks whether an engineer can think at the problem level.

WHAT THIS TESTS Whether the candidate separates the user's underlying goal from any particular solution and can express success as measurable outcomes.

A GOOD ANSWER COVERS The job is the fundamental progress a person is trying to make in a particular circumstance, stated independently of any product or technology: for example, keep my team aligned on what to build next, not use a roadmap tool. Desired outcomes are the measurable criteria by which users judge success, often framed as minimize or increase something, such as minimize the time to know whether a decision is correct or increase confidence that nothing was missed. As an engineer, you contribute by grounding these in feasibility: clarifying what is technically possible, what data exists, what constraints (latency, cost, privacy) shape outcomes, and where the hard problems are, so the team frames outcomes that are both valuable and achievable. The crucial difference from listing features: features are candidate solutions. In JTBD you first nail the job and outcomes, then let multiple feature ideas compete on how well they satisfy them, which prevents anchoring on one solution prematurely.

COMMON WRONG ANSWERS Jumping straight to feature ideas. Confusing a solution (a dashboard) with the job (stay aligned). Writing vague outcomes that cannot be measured. Ignoring feasibility, producing outcomes the team cannot deliver.

LIKELY FOLLOW-UPS How do you phrase a measurable outcome statement? How do features get prioritized against outcomes? How does this differ from gathering feature requests? Where does technical feasibility enter?

ONE CONCRETE EXAMPLE In a workshop for a deploy tool, instead of proposing a rollback button (a feature), the team defines the job: safely ship a change without breaking production, with outcomes like minimize time to detect a bad deploy and minimize time to recover. The engineer notes that detection requires metrics instrumentation that already exists, so several solutions (auto-rollback, canary, alerts) can now compete on those outcomes.