Mastering the Discovery Phase: Build What Works in the Real World

Discovery makes the difference between software that looks good in demos and software that actually works on the floor. It’s the practice of uncovering real workflows, hidden constraints, and user needs before they turn into expensive rework. Done well, discovery keeps teams aligned with operations, reduces go-live risks, and ensures every feature serves the way people really work — not the way we assume they do.

In demos, software can look perfect. In production, reality wins. We once shipped a modern rewrite (from JSP to SPA) of the huge module that passed every internal review. On site, the first users rejected it within hours — not for bugs, but for workflow mismatches. That experience reinforced a core idea: discovery reduces the gap between what we plan and how people actually work.

A useful way to think about it is the “iceberg” model. What stakeholders say they want is the visible tip. Below the waterline are real workflows, constraints, exceptions, and decision points. If we design only for the tip, the rollout will struggle. 

Discovery is not one kickoff meeting or a feature list. It is a continuous practice: understand the users and their environment, clarify value, and test risky assumptions early. In practice, this looks simple:

• Spend time where the work happens (shadowing and observation). A short visit often reveals more than long email threads.
• Run focused user interviews. Ask “why” to uncover constraints and edge cases that specs miss.
• Put rough versions in front of people early: paper mockups or a small clickable prototype. The point is to learn before code locks in assumptions.
• Do document analysis: review existing legacy specs, manuals, and system logs. They often describe rules users forget to mention.

Good requirements are short, concrete, and testable. I prefer user stories with clear acceptance criteria, and I use BDD to express behavior with examples in plain language. Keep the spec as a single source of truth, version it, and record changes so everyone knows what and why something changed.

A small example:

Story: As a loading supervisor, I want to see if a pallet is on hold during loading

Scenario: Show error message loading pallet on Hold

Given a pallet with an active hold

When the pallet is scanned at the loading

Then the system shows the error message and blocks loading

This short scenario clarifies intent, data, and how we will test it.

A rewrite is not a copy‑and‑paste exercise. Moving from JSP pages to a single‑page application (SPA) changes both technology and process. Use the migration to rediscover what matters: which behaviors are essential, which are accidental, and which to remove.

Two practical rules helped us:

1. Separate parity from enhancements. Protect operations by matching essential behavior first; add improvements later.
2. Release in phases. Use small pilots and feature flags to limit risk and learn with real users before full rollout.

Also, prepare users early with short demos and training so there are no surprises on go‑live day. 

Context. The project was a year‑long rewrite of a WMS module (JSP → SPA) with several new features requested during the build. The Product Owner was US‑based; the delivery team was remote. In practice, Internal demos and sign‑offs were green.

Go‑live day. When operations started, the first shift tried the new module and quickly escalated: “This isn’t how we work.” The usage of the new module was paused.

Immediate impact. Deployment failed. Urgent rework was needed. The new module was not “broken,” but it did not fit the way the warehouse actually ran the process.

Root causes:

• No End-User Feedback Loop: Requirements were never validated with the actual people who do the job.
• Misinterpreted Needs: The PO and team made assumptions about warehouse processes that were incorrect.
• Communication Gaps: Remote PO = Filter. Team lacked direct user insight/context.
• Late Discovery of Issues: No early user testing; misalignment surfaced only at go-live (too late).

Key Lessons:

• Involve users throughout. Early and frequent engagement (demos, reviews, short feedback sessions) reduces surprises.
• Verify process alignment. Continuously compare the software flows with real‑world workflows and adjust requirements when gaps appear.
• Improve communication. Reduce layers between the delivery team and user representatives; enable direct or near‑direct conversations.
• Iterate & pilot. Split large changes into smaller releases or pilots to gather feedback early and often. 

The central idea behind our recovery plan was simple: shift validation left. Instead of waiting for Test or Deploy to tell us what’s wrong, we bring feedback into Requirements and Design. Catching issues early costs less and avoids last‑minute surprises.

Validation isn’t a final gate; it’s a heartbeat. After every meaningful change, ask: how will we know this works in the real world? Problems found late are expensive and disruptive; problems found early are manageable. 

• Involve the right people. Combine end users, stakeholders, and the delivery team early and often; each sees different gaps.
• Use multiple methods. Don’t rely on documents alone. Walk through tasks together, run small demos, and let users try prototypes. More angles mean fewer blind spots.
• Make “Done” unambiguous. Acceptance criteria should be clear and testable so there is only one correct interpretation.
• Test with real users and workflows. Do UAT with the actual tasks and data that matter before the full release; small controlled pilots are even better.
• Iterate and adapt. Deliver in increments, collect feedback, and be ready to change plans based on what validation shows.

Discovery is a team effort. Encourage developers and QAs to ask “why” and challenge assumptions. Share user context with the whole team, not only the PO. Create direct contact between the team and user representatives — context travels better face‑to‑face than through long chains.

Discovery aligns delivery with real operations. Observe where the work happens, capture behavior as concise stories with clear tests, validate changes in small steps, and use migrations to rediscover what matters. Teams that work this way cut rework, reduce go‑live risk, and deliver software that fits.