Skip to main content

Part V (k) - Product Discovery for Engineers

HARD TRUTH: MOST FAILURES START BEFORE IMPLEMENTATION

Most costly engineering mistakes are not code quality failures.

They are direction failures: solving the wrong problem, overbuilding low-value scope, or ignoring core constraints until late.

Top engineers treat discovery as engineering ownership, not pre-work.

PROBLEM BRIEF TEMPLATE​

Before discussing solutions, write a one-page problem brief:

  • User segment affected
  • Current pain and workaround
  • Frequency and severity
  • Business impact
  • Why now
  • Success metrics

Rules:

  • Keep it falsifiable
  • Avoid architecture details at this stage
  • Tie all language to user behavior and measurable outcomes

Example One-Page Problem Brief​

Problem: Verification delays are causing activation drop-off.
User segment: New self-serve signups on web
Observed pain: 27% of users abandon before first verified session
Current workaround: Support manually verifies high-value accounts
Business impact: Slower activation and higher support load
Why now: Paid acquisition is increasing top-of-funnel volume
Success metric: Reduce verification-related drop-off from 27% to <15%
Non-goals: Full onboarding redesign, account settings cleanup

This level of specificity is usually enough to align product, engineering, and analytics before solution work starts.

CONSTRAINT MAPPING​

Discovery fails when teams discover hard constraints too late.

Map constraints upfront:

  • Security and privacy
  • Regulatory or legal limits
  • Existing architecture boundaries
  • Team capacity and time constraints
  • Cross-team dependencies

War-story pattern: teams that ignore constraints early end up rewriting architecture late.

Constraint Map Questions​

For each initiative, answer these explicitly:

  • What data cannot leave a region or system boundary?
  • Which team must approve a launch?
  • Which dependency has the longest lead time?
  • Which assumption becomes expensive if it is wrong?
  • What part of the rollout is hard to reverse?

Good discovery exposes these before design commitment.

HYPOTHESIS-DRIVEN SCOPING​

Break scope into hypotheses:

  • What must be true for this feature to matter?
  • What is the smallest experiment to test it?
  • Which metric will validate it?
  • What do we do if metric fails?

This keeps planning honest and kills "big bang" scope inflation early.

Example:

  • Hypothesis: faster checkout increases conversion.
  • Experiment: reduce checkout steps for one segment.
  • Metric: conversion delta vs control.
  • Decision: expand only if threshold reached.

RISK-FIRST PRIORITIZATION​

Prioritize work by learning value, not by visual polish:

  • Highest uncertainty first
  • Highest irreversibility next
  • Highest blast radius next
  • Lowest-value refinements last

Field rule: discover fatal flaws when change is cheap, not during launch week.

Discovery Exit Criteria​

Discovery is complete when the team can answer all of the following without hand-waving:

  • What are we building first?
  • What are we explicitly not building now?
  • What signal will tell us the first release worked?
  • What signal will tell us we were wrong?
  • What risk is still open and who owns it?

If these answers are fuzzy, the team is not ready to estimate implementation honestly.

HANDOFF TO DELIVERY​

Discovery is complete only when implementation can start with minimal ambiguity.

Handoff checklist:

  • Shared problem statement
  • Agreed goals and non-goals
  • Success metrics with owners
  • Scope boundaries
  • Rollout and rollback plan
  • Known dependencies and risks

If this handoff is weak, fast delivery becomes expensive rework.

War-Story Mini-Case: Built Fast, Missed the Problem​

Timeline:

  • Week 0: Team commits to full onboarding wizard redesign based on anecdotal feedback.
  • Week 4: Wizard launches; activation moves only +1.2%.
  • Week 5: Funnel analysis shows largest drop occurs at email verification delay.
  • Week 6: Team rewrites discovery into a one-page problem brief focused on verification friction.
  • Week 8: Verification-speed experiment ships; wizard polish is deferred.

Key decisions:

  • Stopped investing in broad UX redesign before validating root friction.
  • Chose hypothesis-first scope over feature-complete scope.
  • Prioritized highest-friction bottleneck over highest-visibility UI work.

Outcome:

  • Activation improved by 11%.
  • Delivery scope reduced to roughly one-third of the original plan.

OUTPUT ARTIFACT​

For every major initiative, publish:

  • One-page Problem Brief
  • Hypothesis and experiment plan
  • Constraint map
  • Discovery decisions log

This creates a reliable bridge from product intent to engineering execution.