A processing-workflow software idea can become too broad before the first interview. A founder hears about disconnected records, repeated questions and difficult handoffs, then sketches a platform to manage everything. The result may look complete while the underlying problem remains vague. A better first objective is to understand one recurring administrative exchange well enough to test a small product around it.
Discovery should produce evidence a team can use to make a decision. It may support a prototype, reveal a narrower opportunity or show that the current process is already adequate. All three outcomes are useful. The plan below concentrates on business research, information flow and product boundaries. It does not offer clinical instructions or decide the regulatory status of a proposed product.
Choose a specific exchange
Describe the handoff using roles, an object and a reason for the exchange. For example, an operations coordinator sends a service request to an equipment-support contact because an administrative issue needs clarification. This sentence is more testable than a goal such as improving the entire department. It identifies who to interview and what kind of example to ask them to describe.
Avoid writing a solution into the problem statement. If the statement says people need a dashboard, it has already chosen an interface. Ask instead what they need to know, when they need it and what they do when the information is missing. A dashboard may follow, but a clearer notification or a better document reference could address the same issue with less complexity.
Recruit both sides of the handoff
An exchange has at least two perspectives. Interview the sender and recipient separately before asking them to map an example together. Each may use a different name for the same object or understand completion differently. These differences are valuable findings. They can show why an apparently straightforward request returns for clarification or disappears into an informal queue.
Prepare a consistent interview guide. Ask participants to describe a recent representative example, the systems involved and the information they needed. Request permission before viewing any real records, and keep the research within an agreed data-handling plan. Fictional examples or redacted demonstrations can be enough for early mapping. The founder does not need a large collection of sensitive operational data to learn which roles own a handoff.
Map what happens, including exceptions
A simple flow should show the trigger, the information gathered, the recipient, the possible responses and the way completion is recorded. Add the common exception: an incomplete request, an unavailable contact or an item sent to the wrong team. Exceptions often determine whether a software concept is useful. They reveal the work that people perform outside the tidy process shown in a presentation.
Keep observations separate from proposed changes. One layer can record what participants described. A second can record questions or possible improvements. Mixing the two makes it difficult to know whether a feature responds to a real event or to the founder's expectation. At the end of the mapping session, ask both participants to identify any part they disagree with. Record the disagreement rather than resolving it by assumption.
Define the product boundary in writing
A first concept should state the administrative job it supports and the decisions that remain with people or other systems. This boundary helps the team evaluate feature requests. A request tracker, for example, may organize ownership and messages while leaving equipment operation and technical judgment outside its scope. New features should be assessed against that statement before they enter a development plan.
The FDA overview of reusable-device reprocessing is useful category context. The actual intended use of a software product deserves qualified professional assessment. Early discovery can support that assessment by documenting what the product proposes to do, which users it serves and how its output would be used. A clear record is more helpful than a vague claim that the tool is purely administrative.
Agree on the meaning of a status
Status labels can hide substantial disagreement. Open, assigned, waiting and complete may sound obvious until two roles explain them differently. Define what event creates each status, who can change it and what information is required. A request may be answered without being resolved, or closed by one team while another still needs a follow-up. The product model should reflect the distinction that matters to the chosen workflow.
Test the vocabulary on a few fictional cases before designing elaborate screens. Ask participants where each case belongs and what should happen next. If they disagree, explore the reason. It may indicate a missing status, but it may also reveal an organizational question software cannot settle. The discovery report should identify that dependency clearly so the founder can make an informed product decision.
Prototype the smallest complete journey
A useful prototype includes enough of the journey to test ownership and understanding. For a request concept, that might mean creating a record, reviewing its details, requesting clarification and closing the loop. Use a limited set of realistic fictional information. The purpose is to see whether participants can interpret the same record and identify the next action, rather than to impress them with a populated dashboard.
Give participants a task without describing the intended click path. Watch where they pause and ask what they expect to happen. Record the exact confusion and its consequence. A participant who finds the right button but misunderstands the status has not completed the information task. Those observations create specific design work for the next version and help avoid adding features in response to vague feedback.
Resolve access and record ownership early
A product that connects internal teams and outside suppliers needs an account model suited to that relationship. Determine who can see a request, who can invite another participant and who owns the record after a staff change. Discuss how users leave and what happens to their access. These questions affect the data model and the pilot agreement, so they belong before a broad integration effort.
The CDC guideline for healthcare facilities shows the specialized context surrounding the work. It should remain distinct from a startup's product assumptions. For discovery, the team's task is to understand administrative information needs while qualified stakeholders review the wider implications of the proposed system. Keep that division visible in research notes and demonstrations.
Make a decision at the end of discovery
The final output can be concise: a workflow map, an agreed vocabulary, a prototype findings list and a statement of unresolved dependencies. Add a recommendation to proceed, narrow the idea or stop. Tie that recommendation to what participants demonstrated. A decision based on observed confusion is stronger than one based only on enthusiastic reactions to a presentation.
For a potential Sterilizes software company, this process would give the first product a specific job under a clear category name. The founder could introduce the company, demonstrate one well-understood handoff and explain the next research milestone. Sterilizes.com would be a consistent home for that focused proposition, while the product earns its place through careful discovery and useful execution.