Healthcare software can fail long before anyone writes a line of production code. It fails when the team frames the problem around the org chart, the buyer, or the existing form instead of the work people are actually trying to do.
I learned this from years in clinical care and nursing operations. A workflow that looks clean from a distance often depends on interruptions, judgment, informal handoffs, and exceptions. Those are not edge conditions. In many healthcare settings, they are the work.
Late feedback is not discovery
Teams often bring frontline staff into the process after a product is already coherent. At that point, the conversation is usually about training, adoption, or small interface changes. The most expensive assumptions have already hardened.
Discovery should begin earlier. Ask nurses and operators to walk through a real recent example. Map what information was available, what was missing, who made the decision, what happened when the normal path broke, and which workaround kept the work moving.
Look for the exception path
The normal path tells you how the process is described. The exception path tells you how the system behaves under pressure. That is where hidden dependencies, safety risks, and trust failures become visible.
A useful product brief should therefore include the standard sequence, the common exceptions, the escalation path, the accountable person, and the evidence that would change a decision.
The practical test
Before a team commits to a solution, it should be able to answer one question: what did we learn from a frontline workflow that materially changed our product decision?
If the answer is nothing, the team may have conducted validation theater rather than discovery. Frontline participation matters when it changes the model, not when it merely confirms that the interface is understandable.