Consultative Discovery and Requirements Gathering Questions

Situation: Product handed over qualitative research suggesting a new workflow that should improve task completion.

Clarifying questions I’d ask researchers (to make findings engineering-actionable):

• Sample & methods: How many participants, recruitment source, demographics, and qualification criteria? (e.g., power users vs. new users)
• Context & tasks: What exact tasks were participants asked to perform? Were they moderated, remote, guerrilla tests, or in-product sessions?
• Observed behaviors: Which user actions/steps did you observe vs. infer? Any screen recordings, transcripts, or event logs?
• Frequency & magnitude: How often did the pain occur (percent of sessions) and how severe (time lost, errors)?
• Edge cases & blockers: Were there users who failed entirely? What preconditions were required for the workflow to succeed?
• Confidence & bias: Any researcher confidence level or known biases? Were findings consistent across participants?
• Hypothesis & outcome: What user hypothesis are you asserting (e.g., "reduces time to complete X")?

Converting insights into measurable acceptance criteria:

• Translate behaviors into metrics:
  • Task success rate >= 90% (was X% before)
  • Median time-on-task reduced by >= 25% (from baseline)
  • Error rate per task <= 5%
  • Net Promoter Score / SUS improvement of N points (if tracked)
• Define instrumentation: exact events, properties, and user segments to log (start, step-complete, error, abandonment).
• Define rollout gates: e.g., no critical errors, performance within 10% of baseline, and monitoring alerts.

Prioritized experiments:

• Quick wins (low effort, high impact): prototype A/B test that swaps in the new workflow for 10% traffic; measure time-to-complete, success, abandonment. Duration 2–4 weeks or until statistical significance.
• Medium: feature-flagged gradual rollout with automated canary metrics and qualitative follow-ups (session replays, targeted interviews).
• High-effort: full redesign with backend changes—use RICE (Reach, Impact, Confidence, Effort) and technical risk assessment to prioritize.
• Safety: include rollback conditions and guardrails (error rate spike > X, latency > Y ms).
• Post-experiment: combine quantitative results with a small follow-up moderated study to validate UX nuances.

Why this works: asking precise questions converts qualitative signals into measurable hypotheses; instrumentation + incremental experiments let engineering validate impact with minimal risk and clear acceptance criteria.

Situation: PM sets a hard deadline for a complex feature that isn’t realistically deliverable with full scope.

Conversation script (concise, use in meeting/email):

• Opening: “Thanks — the deadline is clear. I’ve reviewed the scope and technical unknowns. I want to align on what must be delivered vs what can shift so we hit the date without undue risk.”
• Clarify outcomes: “What are the top 1–2 user/business outcomes we must achieve by the deadline?”
• Proposal: “To meet the date, I recommend: (A) cut X, (B) defer Y, (C) reduce complexity of Z. If you prefer preserving X, we’ll need to move the date or add resources—here’s the impact.”
• Confirm trade-offs: “Agreeing to these changes will reduce scope by ~N days and lower risk from high to medium. Are you comfortable with that?”
• Close: “I’ll document the decision, risks, and next steps and share it for sign-off.”

Suggested items to cut/defer/reduce:

• Cut (remove non-essential): admin-only reporting, secondary analytics dashboards, optional UI polish.
• Defer (MVP later): multi-tenant support, integrations with secondary partners, internationalization.
• Reduce complexity: replace eventual consistency with simpler synchronous flow, use a feature flag + basic UI rather than fully instrumented rollout, limit config options.

How I document agreement and risks:

• Create a one-page Decision Record (title, stakeholders, chosen scope, items cut/deferred/reduced, rationale, date).
• Add entry to Jira: link tickets moved to “Deferred” sprint/backlog with labels and acceptance criteria for later.
• Log risks in the project RAID (Risk log): describe each risk, likelihood, impact, mitigations, and owner.
• Share summary email and request explicit sign-off (PM, engineering lead, QA, UX).

Risks introduced and mitigations (examples):

• Risk: Reduced validation causes user errors. Mitigation: add monitoring, rollback plan, and hotfix owner.
• Risk: Deferred integration blocks downstream teams. Mitigation: mock contract/API and timeline for integration sprint.

This approach aligns user priorities, preserves delivery confidence, and creates a clear audit trail so we can safely iterate after the release.

Requirements / clarifying questions

• What events trigger notifications (transactional, system, marketing, reminders)? Which are high-criticality?
• Per-channel availability: Do all users have email/push/in-app enabled by default? How do we verify push tokens / email deliverability?
• User preference model: Do users set per-channel, per-event, per-frequency preferences? Are there global “do not disturb” windows or timezone rules?
• Frequency caps: Are caps per-event, per-channel, per-day, or per-group? Should caps be soft (throttle) or hard (drop)?
• SLA for “timely”: e.g., <5s for transactional, <1h for reminders/marketing?
• Regulatory constraints (GDPR/CAN-SPAM) and opt-in/opt-out requirements?
• Metrics / KPIs: which define “spammy” (open rate, click rate, unsubscribe rate, complaint rate)?
• Personalization: Who owns relevance/segmentation rules—product or ML team?

Phase 1 scope (minimal viable safe system)
Goals: deliver reliable, timely transactional + basic preference controls; enforce simple anti-spam caps.
In-scope:

• Event ingestion pipeline (Kafka) → Notification service → Channel adapters (email via SES, push via FCM/APNs, in-app via websocket/DB)
• User preferences: per-channel ON/OFF, timezone, global DND window
• Criticality tiers: HIGH (must deliver), NORMAL (best-effort)
• Simple frequency caps: max 5 notifications/day per user across non-HIGH events; per-channel caps of 3/day
• Dashboards: deliveries, opens, unsubscribes, complaint rate
  Acceptance criteria:
• 99.9% of HIGH notifications delivered within SLA (configurable)
• Preference changes effective within 60s
• Caps enforced: no user receives >5 non-HIGH notifications/day in 10k user sample
• Monitoring alerts on complaint rate >0.5% or unsubscribe spike

Measure & enforce “not spammy”
Measurement:

• Per-user daily notification count, per-channel counts
• Engagement metrics: open/click/CTR, unsubscribe/complaint rates, time-to-action
• Cohort analysis: retention vs notification frequency
  Enforcement:
• Server-side enforcement layer that evaluates: event criticality, user prefs, current counts, DND, TTL. It returns: SEND, QUEUE, COALESCE, or DROP.
• Coalescing: batch similar events into single digest (e.g., multiple comment notifications → 1 digest)
• Adaptive throttling: if user-level engagement drops below threshold, progressively reduce non-HIGH sends and route to digest mode
• Backoff and suppression windows after unsubscribe/complaint
  Operational controls:
• Feature flags to toggle marketing channels
• Monitoring + automated alerts and daily reports for product owners
• A/B experiments to optimize caps and measure business impact

Trade-offs / next phases

• Phase 2: per-event preferences, ML relevance scoring, smart digests, rate limits per category, richer analytics.

Timeboxed agenda (30 minutes)

• 0:00–2:00 — Goal & success metrics reminder (PM)
• 2:00–8:00 — Design walkthrough (visuals, states, responsive behavior)
• 8:00–16:00 — Engineering feasibility & constraints (performance, tech gaps)
• 16:00–22:00 — Scope negotiation & prioritization (MVP vs. niceties)
• 22:00–27:00 — Risks, dependencies, rollout plan
• 27:00–30:00 — Confirm concrete outputs, owners, next steps

Key clarifying questions

• To Product:
  • What user outcome/metric must move and by how much? (primary success metric)
  • Which elements are non-negotiable vs. optional?
  • Rollout constraints (A/B test, feature flag, launch date)?
• To Design:
  • Which breakpoints/states must be implemented now? Are there motion/accessibility requirements?
  • Are there assets/specs ready (Figma links, token values)? Any unknown edge states?
• To Engineering:
  • What are the implementation risks (data model, API, caching, CDN, load)?
  • Estimated dev + QA effort for MVP and for “delighters”? Any hidden infra work?

Concrete outputs expected (at meeting end)

• Tickets created in backlog:
  • FE ticket(s): component implementation, responsive states, accessibility — Owner: Frontend Engineer — Acceptance criteria: visuals match Figma; keyboard focus order; ARIA labels; passes Lighthouse perf threshold X.
  • BE ticket(s): API changes/cache invalidation — Owner: Backend Engineer — Acceptance criteria: endpoints return required fields; tests cover edge cases; latency < Y ms.
  • QA ticket: test plan and regression list — Owner: QA — Acceptance criteria: pass on X browsers/devices; smoke tests for rollout.
  • Product/Design follow-up: content and analytics events — Owner: PM/Designer — Acceptance criteria: final copy, image assets, tracking spec linked.
• Rollout plan: feature-flagged A/B rollout owner (PM or Eng) with target % and rollback condition.
• Risks & mitigation list with owners and due dates.
• Calendar: sync for handoff + demo before deploy.

This keeps the meeting decisive: align on metric-driven scope, frame MVP vs. polish, and leave with actionable tickets and clear owners.

Clarifying questions

• What do we mean by “startup time”? Cold start, warm start, app-process launch, or first meaningful paint?
• Target platforms and OS versions (iOS/Android, min versions)?
• Current baseline metrics (cold/warm start times, percentiles) and SLAs or competitor benchmarks?
• Which user journeys matter at startup (auth screen, onboarding, deep link handling)?
• Any constraints (third‑party SDKs, legacy code, analytics) or release deadlines?

Decompose into spikes and stories

• Spike A — Measurement & baseline (instrument startup, gather p50/p95, reproduce on device farm). Outcome: reliable benchmarks and profiler traces.
• Spike B — Root-cause analysis (identify top causes: I/O, main-thread work, heavy libs).
• Stories (based on spike outcomes): defer non-critical init, lazy-load modules, move work off main thread, optimize image loading, reduce APK size, replace/trim SDKs, add splash/placeholder improvements.
• Integration & QA stories: add automated startup regression tests, device matrix performance tests, telemetry dashboards.

Estimation method

• Use two-phase approach: T-shirt (S/M/L/XL) for the epic and initial planning; story points (Fibonacci) for individual stories after spikes.
• Rationale: T-shirts communicate rough effort quickly; story points give team-calibrated velocity once unknowns are reduced.

Assumptions to record

• Devices and OS targeted, acceptable perf thresholds, availability of test devices, whether we can remove/modify third‑party SDKs, estimated time to get access to analytics data.

Communicating uncertainty

• Present a confidence band: best-case / likely / worst-case estimates and probability (e.g., 50%/80% confidence).
• Mark spikes as “reduce uncertainty” with timeboxed budgets (e.g., Spike A: 3 days).
• Share risks and mitigation: blocker risks, unknown third‑party behavior, and contingency plans.
• Commit to re-estimating after spikes and deliver a short summary to stakeholders with data (benchmarks) and recommended next steps.