Describe the decision your product supports
“We want an app” leaves too much open. A more useful starting point describes who uses the software, the information they have, the output they need and what they do next.
For example, an application might receive a recorded examination and prepare a report for review. The surrounding workflow matters as much as the processing step. Who identifies the patient? What happens when the recording is incomplete? Where does the report go?
Intended use also informs regulatory classification. Health Canada explains that classification depends on the software’s intended use and the applicable rules. Establish that direction with your regulatory specialists before treating an early architecture as settled. Health Canada’s SaMD guidance
Choose what the first phase needs to prove
A proof of concept should answer a specific uncertainty. That might be whether a capture flow works on the intended devices, whether an existing model can be integrated into an application, or whether a hospital interface accepts the required report.
Agree on the inputs, the demonstration and the evidence that will make the result useful. Also record what the exercise does not establish. A prototype running with synthetic data does not establish clinical performance or readiness for deployment to patients.
In our clinical report integration engagement, the useful milestone was a complete delivery flow verified in development against a simulated EHR. Keeping that boundary explicit made the next release decision clearer.
Bring the constraints into the room
Before estimating delivery, collect the information that changes the shape of the work:
- The target users, devices and operating environments.
- Existing software, model interfaces and integration dependencies.
- Available test data and how the team is permitted to use it.
- Quality-system procedures and the people who review changes.
- The next commercial or product milestone and the budget available for that phase.
Unknowns are acceptable. Naming them lets the team investigate them instead of hiding them inside an estimate.
Decide who owns each responsibility
An external product team can handle design, application engineering and delivery without taking over every responsibility of the device manufacturer. Agree on product ownership, regulatory strategy, clinical validation, quality approvals and operational support.
If you already have engineers, identify where a partner should integrate with their work. If you do not, establish a product decision-maker on your side and a delivery lead on the partner’s side. A complete team still needs clear decisions from the business.
Leave with a usable first scope
The first scope should identify the workflow to build, the uncertainty to test, the acceptance criteria and the people who will review the outcome. It should also explain what follows if the initial approach does not work.
We use this conversation to shape SaMD product development engagements around the actual product. Tell us where you are starting and what needs to happen next.