Product discovery turns an idea into a set of decisions a team can build from. Its value is practical: finding out which problem matters, what a useful first release must do and which assumptions could make the project fail. The output should guide delivery rather than sit in a presentation.
Understand the work as it happens today
Ask people to show you the task they currently perform. Look at the spreadsheets, messages and workarounds involved. What gets copied between systems? Where do they wait for someone else? What mistakes create extra work?
Separate what people request from the problem beneath it. A request for a dashboard might really be a need to know which orders require attention. That distinction changes both the interface and the amount of software required.
Map roles and the important exceptions
Describe who can view, create, approve or change each type of information. A customer, operator and administrator may interact with the same record but need very different controls.
Map the unsuccessful paths too. What happens when an invitation expires, a document is incomplete or an external service does not respond? These decisions affect the design, data model and support workload.
Identify what could change the plan
Record assumptions about demand, access to data, integrations and operational capacity. Rank them by how damaging they would be if wrong. Test the important uncertainties before polishing low-risk parts of the experience.
A clickable prototype can test whether people understand a journey. A technical prototype can test whether an integration supports it. Choose the smallest experiment that produces evidence for the decision in front of you.
Turn findings into a buildable scope
The handover to development should include the core journeys, roles, content or data requirements and acceptance criteria. Keep a decision log so the team can understand why an approach was chosen.
Define the first release and explicitly defer the rest. If the scope still contains several independent products, reduce it until a real user can complete one valuable job with confidence.
Carry discovery into delivery
Discovery does not make later learning unnecessary. Use reviews and early releases to check whether the original assumptions still hold. Keep the problem visible while allowing the solution to change.
Selfhood’s studio products, including Ronin and Get TLDR, provide concrete examples of different working contexts: coding-agent orchestration and information processing. The useful starting point in either case is the task, not a generic list of app features.