Use case
Product discovery interviews
Product discovery is learning what customers actually need before engineering commits. Fieldwork lets you describe the decision in plain language, then Sofi interviews real users at scale: she probes shallow answers, follows interesting threads, and returns themes your team can weigh against the roadmap.
Why do product teams struggle with discovery?
Discovery often loses to delivery pressure. Teams ship based on internal assumptions, then discover misalignment after launch. When they do run research, moderator scheduling caps sample size at five to eight sessions, which is enough for anecdotes but thin for prioritisation.
Fieldwork Interviews removes the scheduling bottleneck. You write a brief describing what you need to learn. Sofi structures the conversation, runs every session to that plan, and surfaces patterns as interviews complete.
What questions does product discovery answer?
Unmet needs in a workflow your team is about to redesign. Whether a proposed feature solves a problem customers actually feel. What language customers use when they describe the pain, which matters for positioning and in-product copy.
Trade-offs between two directions before either gets a quarter of engineering time. Reasons trial users stall before activation, when analytics shows the drop but not the story behind it.
What this looks like in practice
A B2B product team is debating a workflow automation feature. Analytics shows power users export data manually every week, but the PM is unsure whether automation is the right bet or whether the export itself signals a reporting gap.
They brief Sofi: understand why heavy users export, what they do with the file, and what would need to be true for them to stop. Within two days, sixty customer conversations complete. Themes cluster around three stories: finance needs a board-ready format, operations mistrusts in-app totals, and a minority export because their CRM integration is missing. At that sample the team can see which story is the majority one rather than guessing which of three anecdotes to build for.
The roadmap meeting shifts from "build automation" to "fix trust on totals first, then evaluate export templates." That is the outcome discovery is for: a decision grounded in customer language, not a slide of assumed jobs-to-be-done.
How does Sofi keep discovery interviews rigorous?
Sofi works from a study plan you approve: topics, depth, and what counts as resolved per area. She avoids leading questions and filler praise. When a participant gives a vague answer, she names that and reframes for specificity.
Automated quality signals per session help you spot thin interviews early. Coverage maps show which topics landed across participants, so you know whether a silent area means "not a problem" or "we did not ask well enough yet."
Frequently asked questions
How is this different from a customer survey?
Surveys collect fixed answers to fixed questions. Sofi conducts a conversation: she follows up when an answer is vague, probes for examples, and redirects when someone goes off track. You get language and reasoning, not just a distribution of Likert scores.
When should we run discovery interviews instead of usability testing?
Discovery fits when you are still deciding what to build or whether a problem is real. Usability testing fits when you have a prototype and need to see where people struggle. Many teams run discovery first, then return with a concept test once they have a direction worth evaluating.
How many participants do we need for product discovery?
Enough to rank what you find, not just list it. Eight to fifteen conversations will surface the main patterns, but that is the sample moderator scheduling used to force on you, and it shows that a theme exists without showing how widely it is felt. Sofi runs sessions in parallel with no scheduling, so forty to sixty is a normal discovery read, and prioritisation gets much easier when you can see which of three stories belongs to most of your users rather than to the few people who happened to be free that week.
Can we test multiple feature ideas in one study?
Yes, though clarity improves when each study has one primary decision. You can structure topics around separate hypotheses and read coverage per area. If ideas compete for attention, split them into parallel studies so participant answers stay focused.
What does the output look like for a product team?
Each session produces a transcript, topic coverage status, and emerging themes. Across participants, you see which needs repeated, which objections surfaced, and where answers stayed thin. That package feeds roadmap reviews without waiting for a research report cycle.
Next steps: Fieldwork Interviews, creative testing, and UX research at scale.