Product Discovery Before You Build a Feature
A request for a new feature can sound like a decision already made. A customer says an account screen needs more options. Sales asks for a dashboard. An internal team wants an automated reminder. Each request may point to a real difficulty, but the requested feature is only one possible response. If a product team commits to it immediately, the team also commits time, design work, and engineering capacity before it knows which part of the customer’s work is failing.
Product discovery is the work of understanding that difficulty and examining possible responses before committing to a solution. Atlassian describes discovery as understanding customer needs and business context before deciding what to build. The practical question is narrower than “What do customers want?” It is: For which people, in which situation, is a problem important enough to address, and which response makes sense for them and for the organization? A useful discovery effort ends with a decision that could be acted on, changed, or declined. A collection of interesting interview notes is not yet that decision.
Consider an illustrative appointment service. People who have begun a booking abandon it before confirming a time. Someone proposes a reminder feature. The abandonment could reflect forgotten intent, but it could also reflect unavailable times, confusing eligibility rules, or a booking step that is hard to use on a phone. A reminder addresses only the first explanation. The point of discovery is to distinguish among those explanations while the choice is still open. The same reasoning applies to a commercial product, an internal tool, or a public service, though each will have different users and constraints.
Start with the job that is going wrong
A feature request names an artifact; a problem statement names a person, an attempted task, and the obstruction. That distinction changes the work a team can do. “Build appointment reminders” invites debate about message timing and channels. “People who start booking do not reach a confirmed appointment” invites questions about who stops, where they stop, what they expected, and what prevents them from continuing. The second statement allows a reminder to remain an option without making it the answer in advance.
I would begin with the decision the team needs to make. Is the organization deciding whether to address the booking problem at all, choosing among several responses, or checking whether a particular design works? Those decisions need different information. The GOV.UK Service Manual’s discovery guidance begins with the problem, the people affected, and the constraints before a service is built. Naming the intended result at this point widens the available options.
Scope matters as much as wording. “Improve appointments” is too broad to guide a conversation or a test. “Help first-time applicants identify an appointment they can attend” identifies a group and a task, though the group itself may need checking. The team can then ask whether the difficulty occurs before a time is shown, while comparing times, or after a selection is made. Each location suggests a different next move. The purpose of a tight statement is not to make the team certain. It is to expose what it still needs to learn.
The people in the problem should include those who actually encounter it, not only those easiest to contact. Existing customers may describe the current product well, yet they cannot represent someone who never signs up because the offer is unclear. Likewise, an administrator who buys a service may have a different concern from the person who uses it each day. Before arranging research, name the decision maker, the user, and any person whose work supplies or supports the service. If these roles coincide, say so. If they differ, a single set of interviews cannot silently stand for all three.
The setting deserves the same attention. A user may be able to complete a form but be unable to find a required document, obtain approval, or use the result afterward. A team that examines only the screen it owns can miss the point at which the task actually breaks. The GOV.UK discovery guide asks teams to understand the user’s wider journey and the constraints around a service. For product teams, that means locating the proposed feature within the user’s full task before assuming that a change inside the product will settle it.
Decide what uncertainty is worth reducing
Discovery has a cost. Time spent speaking with users, examining the journey, and trying designs is time unavailable for delivery. The right question is therefore not whether more information would be nice to have. It is whether a plausible finding could change a consequential decision. If every answer would lead the team to ship the same feature, the inquiry needs a sharper question or the decision has already been made for another reason.
The Silicon Valley Product Group’s four-risk framework separates four concerns: whether people will choose a solution, whether they can use it, whether the team can deliver it with its available skills and technology, and whether it works for the business. These are value, usability, feasibility, and business viability. They are separate because a promising answer in one area does not settle the others. People may express a need for appointment reminders, for example, while the proposed reminder still depends on contact details the service cannot reliably use. A usable reminder flow could also fail to address the reason people abandon booking.
I would use the four concerns to identify the next decision, not to force every idea through the same ceremony. If the team does not know whether people actually want to finish the task in the proposed way, spend less time polishing an interface and more time learning about their choices. If the value is clear but a critical integration is uncertain, involve engineers before promising a launch date. If a design looks attractive but the operating team cannot support it, the service cannot be judged on its interface alone. Each uncertainty calls for a different conversation or trial.
The hardest assumption deserves attention early when a wrong answer would make the solution pointless or impractical. In the illustrative booking case, a team could ask first whether suitable appointments exist for the affected users. If they do not, improving the reminder copy will not create appointments. If they do, the team can investigate whether people see and understand them. This sequence is a judgment about what could overturn the proposal, not a universal order of research methods.
An assumption becomes more useful when it is written so that a team can observe something relevant to it. “Customers like convenience” is too elastic; almost any answer can be made to fit. “People who leave the booking flow do so after seeing available times because none work for them” points to a group, a moment, and an explanation that could be contradicted. A team can then decide whether it needs to examine behavior in the flow, speak with people who left, or both. It should also keep a competing explanation visible: perhaps people leave before reaching the times because eligibility is unclear.
Match the research to the question and the people
A research plan can be short, but it needs more than a calendar of interviews. It should state what decision is pending, what the team needs to learn, which people can speak to or show the relevant experience, and what it will do with the result. The GOV.UK guidance on planning user research explicitly connects research questions, participant groups, and methods. That connection prevents a convenient method from becoming the answer to every question.
For an unfamiliar task, a conversation about a recent attempt can reveal the sequence of actions and constraints around it. Ask a participant to walk through what happened, what they tried next, and what they were trying to accomplish. A recollection has limits, so an actual document, message, or screen from that attempt may clarify the sequence if the participant can share it appropriately. In the booking illustration, a person who stopped because no time was available describes a different problem from a person who selected a time but could not understand the confirmation step. The team should preserve that difference instead of averaging both into “booking is difficult.”
For a proposed interface, a task with a prototype asks a more direct question: can someone use this design to do the thing it is meant to support? The participant should attempt the task rather than merely report whether the screen looks good. A favorable reaction to a mock-up can be useful feedback, but it cannot by itself establish that the person can complete a booking or would choose the service in their own circumstances. Usability work answers a question about interaction. It does not automatically answer a question about value.
Other information may be available without recruiting a new participant for every question. Existing feedback can suggest where to look. Product records can locate the point at which a task stops, if the recorded events actually correspond to the steps the team cares about. Support conversations can reveal the language people use when asking for help. None of those sources can explain every motive on its own. If the record shows that users leave after viewing appointment times, the team still needs to learn whether the times, the wording, the price, or some outside obligation drove that choice. Treat observed behavior and a proposed explanation as different things.
Participant choice can distort the answer before a session starts. If the problem concerns people who left a booking flow, interviewing only people who successfully booked will miss the experience at issue. If a service is meant to work for people with different access needs, convenient recruitment can hide barriers that a later design cannot cheaply remove. The GOV.UK research planning guide asks teams to identify the people who can answer their research questions. The practical implication is to recruit for the decision being made, then state openly which groups the team has not yet heard from.
Sample size should follow the question. A few detailed sessions may be enough to uncover a confusing step and revise a prototype, but they do not justify a claim about how common that problem is across all users. A survey can reach more people yet still mislead if it asks a hypothetical question of the wrong group. The GOV.UK guidance ties the choice of research method to the question and participant group. In a product decision, the useful distinction is between learning what may be happening and estimating how often it happens. Those are different jobs, and a team should not borrow the authority of one for the other.
Compare responses before committing to a feature
Once a team understands a problem well enough to consider action, it should keep more than one response available. A proposed feature, a change to an existing step, clearer content, and an operational change can all address different parts of the same task. The GOV.UK discovery guidance places inquiry before the decision about what to build. The lesson for product discovery is simple: the object of the work is a better outcome for the user, not a larger backlog.
In the illustrative booking case, imagine that research finds three distinct obstacles. Some people cannot tell whether they qualify; others see no suitable times; a third group selects a time but misses the final confirmation. Clearer eligibility information, more useful availability, and a clearer confirmation step are different responses. A reminder might help people in the third group if forgetting is the actual issue, but it would offer little to someone who found no usable time. I would separate these groups before selecting a single release to address them all. Otherwise, a visible feature could conceal the more consequential bottleneck.
The team can compare options against the same dimensions: which user problem each addresses, what must be true for it to work, what work it requires, and which uncertainty remains. This comparison need not produce a score. A scored list can make a weak estimate look precise, especially before the team knows the size of a problem or the cost of a dependency. I would prefer a plain account of the choice: “We will clarify eligibility first because affected users cannot decide whether to continue; we will investigate availability separately because wording cannot create open appointments.” That sentence is reviewable. It also tells colleagues what new finding could change the order.
A solution idea should become progressively more concrete only as the decision requires. A rough sketch can expose whether the team is discussing the same interaction. A clickable prototype can reveal whether a person can complete a task. A small operational trial can reveal whether a new process fits the people who must run it. A technical spike can explore a dependency that a sketch cannot answer. The cost of each step should be justified by the uncertainty it addresses. Building a polished interface while a basic constraint remains unresolved spends effort in the wrong place.
That does not mean a team must wait for perfect certainty before delivery. The supplied practitioner guides describe research and testing as ways to reduce uncertainty; they do not promise adoption or a delivery outcome. A product decision is a commitment made with incomplete information. The honest goal is to know which assumptions carry the decision, which have been examined, which remain open, and what the team will watch after release. If the cost of a wrong choice is limited and reversible, a smaller release may be a reasonable way to learn. If the choice is expensive or hard to undo, the team should ask for stronger support before it commits.
Bring delivery and business constraints into the choice
A user-facing idea can fail in the work behind the screen. Appointment availability may depend on a scheduling system, staffing patterns, or rules about who can be offered which time. A team that discovers user interest but never examines these dependencies has only answered part of the question. The four-risk framework makes feasibility and business viability explicit alongside value and usability. Its business concern includes matters such as channels, contracts, and the organization’s ability to support the solution.
I would bring design, engineering, and the people responsible for operating the service into discovery while the response is still negotiable. Their role is not simply to approve a finished concept. An engineer can explain why a proposed availability display depends on data the system does not expose. An operations colleague can explain how cancellations are handled. A designer can show where an apparently small change makes the task harder for someone using a different device or support route. These are not objections to user needs; they are facts that shape which response can actually meet them.
Constraints also need to be distinguished by how movable they are. A fixed external rule may rule out an option or require a different one. An internal process may be adjustable if the benefit warrants the work. The GOV.UK discovery guide includes constraints in the problem space to examine. For a product team, the useful move is to ask who owns a constraint, what changing it would require, and whether the proposed user benefit justifies that cost. Calling every current practice “fixed” narrows the product unnecessarily; calling every rule “negotiable” creates a plan that cannot be delivered.
There is a business question even when users plainly need help. A response may require ongoing support, a different sales promise, or work from another team. If those costs or dependencies are unknown, the team should not describe the concept as ready. It can still decide to investigate it further. The next step might be a conversation with the responsible team or an estimate of the ongoing work rather than another round of interface feedback. The information sought should follow the reason the choice remains uncertain.
Make the decision visible in the roadmap
Discovery should alter what a team plans, or make the existing plan more defensible. If it produces only a presentation while the roadmap remains untouched, the team has not connected learning to a commitment. The GOV.UK roadmap guidance treats a roadmap as a view of direction and priorities that changes as teams learn. It is a planning artifact. It does not show that users have already received the intended benefit.
I would describe the next step in terms of the user problem and the condition the team is trying to change. For the booking illustration, “make eligibility clear before time selection” tells more than “redesign page two.” The latter may be a necessary task, but it is too narrow to explain why the work is on the roadmap. If research later shows that people understand eligibility but cannot find available times, the problem-led statement makes it easier to change course without treating every change as a broken promise.
A useful decision record can be brief. It should say who the decision is for, what problem the team is addressing, which response it chose, what alternatives it considered, and what uncertainty remains. It should also identify the next observation that would cause reconsideration. In the booking illustration, the team might choose clearer eligibility guidance, leave reminders aside, and plan to review whether people reach the time-selection step more often. The statement does not claim that the guidance has solved the whole booking problem. It connects a choice to the observation that would test whether the choice helped.
The record should travel with delivery. If people building the change receive only a feature name, they may optimize the wrong part of the experience. If they understand the user task and the reason for the choice, they can notice when implementation details undermine it. Discovery and delivery therefore need a conversation in both directions. Atlassian’s product discovery guide describes research and testing as ways to reduce uncertainty about an opportunity. In practice, a technical constraint found during implementation may require a new option; behavior after release may require a new account of the problem.
After release, separate three questions. Did the team deliver what it intended? Did the intended people encounter and use it? Did their underlying task improve? A completed ticket answers the first question. Use of a changed screen offers information about the second. Neither alone establishes the third. A team should decide before release what change in the user’s task would count as useful progress, then look for that change without claiming more than the data can show. If the result is ambiguous, the next action is to identify the ambiguity, not to announce success because the work shipped.
Keep discovery proportional to the decision
The phrase “do discovery” can make the work sound like a separate project with a fixed sequence of workshops and reports. It is more useful to ask what choice is coming next. A team considering a major new service may need a broad view of people, constraints, and alternatives. A team changing one confusing step in an established flow may need a narrower round of user work. The GOV.UK discovery phase guide frames its discovery phase as preparation for a decision about further investment. That is a sound discipline even when a commercial team’s cadence differs: learn enough to justify the next commitment, then revisit the question as the work progresses.
There are two ways to waste time here. One is to treat a requested feature as settled and use research only to decorate it with favorable comments. The other is to continue investigating after the team has enough to make the next reversible choice. The remedy for both is a decision deadline tied to a real question. At the start, write down what would make the team proceed, change direction, or stop. If the answers are not known by the deadline, name the remaining uncertainty and decide whether another inquiry is worth its cost.
For a first pass, I would take a live feature request and rewrite it as a user problem. I would identify the affected group and the moment in its task, then list the two or three explanations that would lead to different actions. I would ask which explanation matters most to test before work begins, recruit people who have actually faced that situation, and choose a way to hear or observe what the question requires. I would compare at least two possible responses with design, engineering, and the operating side of the business. Finally, I would record the choice, the unresolved assumptions, and what the team will look for after delivery. That sequence is small enough to use on a real decision and explicit enough to expose a weak one.
Product discovery earns its place when it changes the quality of a commitment. It helps a team move from “someone asked for a feature” to “we understand a particular person’s task, we know why this response is worth trying, and we know what could prove our choice wrong.” The team may still choose to build the original feature. The difference is that the feature now has a reason, a boundary, and a way to learn whether it served the person it was meant to help.