Scientific product discovery.
Scientific product discovery is the work of understanding what should be built before engineering momentum takes over. It connects user routines, scientific evidence, technical constraints, and product boundaries into a plan that can be tested.
Begin with the routine, not the feature list
Research teams often describe needs as features: upload images, run a model, export a report, add notes, build a dashboard. Discovery should step back and ask what repeated routine those features serve. What is the user trying to decide? What information do they check? What creates delay, rework, or uncertainty? Which part of the workflow is painful enough to justify a product?
Vanguard uses this routine-first framing because scientific products succeed when they reduce real operational friction without weakening the evidence behind the work.
Map evidence and constraints together
A product may be desirable but unsupported by the available evidence. Discovery should review data availability, data quality, validation needs, privacy boundaries, user roles, device constraints, and integration requirements. These details shape scope more honestly than a generic roadmap.
For AI-enabled products, discovery should also clarify whether the model will automate, assist, prioritize, summarize, or simply surface patterns for human review. Those are different products with different risk profiles.
Interview around real artifacts
Scientific teams often explain their work best when they are looking at the artifacts they already use: spreadsheets, notebooks, instrument exports, screenshots, labels, reports, protocols, and message threads. Discovery should use those artifacts to understand where context is lost, where duplicate entry happens, and where decisions depend on memory rather than visible evidence.
This kind of artifact review helps prevent a product from becoming an abstract workflow diagram. It keeps the team close to the messy details that decide whether the final tool will feel useful in practice.
Prototype the decision surface
A prototype should test the decision surface, not only the visual style. It should show what users would see when evidence is complete, missing, uncertain, rejected, or corrected. This helps teams discover whether the product communicates scientific limits clearly enough for real use.
- Write the main user decision in one sentence.
- Identify the minimum evidence needed to support that decision.
- Sketch the review states before building the database around them.
- Define what the product should refuse to do.
- Test the prototype with realistic edge cases, not only ideal records.
Turn discovery into build criteria
Discovery should produce practical criteria: what is in scope, what is out of scope, what must be validated, what must be logged, what users need to trust, and what risk remains. This prevents the team from treating a promising demo as a finished product.
Those criteria should be revisited after the first pilot or prototype review. Scientific products often reveal new constraints only when users apply them to real records, real devices, and real time pressure.
For Vanguard, strong discovery saves time because it narrows the product to a useful, testable shape. It makes the later engineering work calmer, clearer, and more defensible.