What To Ask Before Building A New Feature

What Problem Are We Actually Solving?

Before a team commits time, budget, and engineering effort to a new feature, the first question should be simple: What problem are we actually solving? It is surprisingly easy to start with a proposed solution—“Let’s add a dashboard,” “We need an AI assistant,” or “Customers keep asking for more filters”—without clearly defining the problem behind it.

A strong feature idea starts with a real user need, not just a request. Users often describe what they think they want, but product teams need to understand what is causing the friction. For example, a customer may ask for more reporting options, but the deeper problem might be that they cannot quickly explain performance to their manager. In that case, the right solution may be a better summary view, an export, an automated email, or improved data labeling—not necessarily a large reporting module.

To clarify the problem, ask questions such as:

• Who is experiencing this problem? Is it a specific customer segment, a high-value account, new users, power users, or internal teams?
• How often does the problem happen? A frequent pain point may deserve more attention than an edge case.
• What is the impact? Does it slow users down, prevent them from completing a task, increase support requests, or reduce trust in the product?
• What are users doing today to work around it? Workarounds often reveal urgency and help teams understand the true workflow.
• What evidence do we have? Look for patterns in customer interviews, support tickets, product analytics, sales calls, usability tests, and churn feedback.

Our team’s view: a feature should not move forward until the problem can be explained in plain language. A useful problem statement might sound like this: “New users are abandoning setup because they do not understand which settings are required before they can invite their team.” That statement is specific, observable, and tied to a real behavior. It gives designers, engineers, and stakeholders a shared target.

By contrast, a vague statement like “We need to improve onboarding” is too broad to guide good decisions. It may be true, but it does not tell the team where users struggle, why it matters, or what success should look like.

The goal at this stage is not to reject ideas. It is to make sure the team is solving the right problem before deciding what to build. When the problem is clear, feature discussions become more focused, scope decisions become easier, and the final product is more likely to create value for both users and the business.

Who Is This Feature For?

Once the problem is clear, the next question is: Who is this feature actually for? A feature that tries to serve every possible user often becomes too broad, too complicated, or too watered down to solve anyone’s problem well. Defining the intended audience helps the team make sharper decisions about design, scope, messaging, and priority.

Start by identifying the primary user group. This may be a specific customer segment, role, plan type, behavior pattern, or stage in the user journey. For example, a feature might be designed for first-time users completing setup, account admins managing permissions, experienced users analyzing advanced data, or support teams resolving customer issues faster. Each of these groups has different expectations, workflows, and levels of product knowledge.

It is also useful to separate the person requesting the feature from the person who will use it. In many products, a buyer, manager, or stakeholder may ask for something on behalf of a team, but the daily user may have different needs. Building only for the loudest requester can lead to a feature that satisfies a conversation but misses the real workflow.

Helpful questions include:

• Who will use this feature most often?
• What job are they trying to complete?
• Where does this feature fit into their existing workflow?
• What level of experience do they have with the product?
• Are there users who should not see or need this feature?
• Will this feature help one segment while making the product harder for another?

The goal is not to exclude users unnecessarily. It is to make the first version focused enough to be useful. A clear audience statement might sound like this: “This feature is for team admins at mid-sized companies who need to review user access before quarterly security audits.” That statement gives the team practical context: the user is an admin, the company size matters, the task is access review, and the timing is tied to a recurring business need.

By contrast, a statement like “This is for all customers who want more control” is too vague. It does not explain who needs control, what kind of control they need, or why it matters.

When teams know exactly who they are building for, they can make better trade-offs. They can choose the right level of complexity, write clearer in-product copy, prioritize the most important workflows, and avoid adding options that only create clutter. In our experience, a well-defined audience is one of the strongest safeguards against feature bloat.

How Do We Know Users Want This?

A feature idea becomes much stronger when it is supported by evidence. Before building, teams should ask: How do we know users actually want this, and how do we know it matters enough to prioritize? A single customer request, stakeholder opinion, or competitor comparison may be worth exploring, but it should not be treated as proof on its own.

Good validation looks for patterns. If multiple users describe the same frustration, if analytics show repeated drop-off in the same workflow, or if support teams keep answering the same “How do I do this?” question, the feature may be solving a meaningful problem. The goal is not to collect endless research. It is to gather enough reliable information to reduce guesswork before the team invests in design and development.

Useful validation methods include:

It is important to distinguish between interest and behavior. A user saying “That sounds useful” is helpful, but it is weaker evidence than seeing them repeatedly struggle with a workflow, create a workaround, request the same capability more than once, or use a simple prototype. Behavior usually gives teams a clearer signal than polite feedback.

Teams should also pay attention to who is asking. A request from one large customer may deserve attention, but the team still needs to understand whether the need is specific to that account or shared by a broader segment. Similarly, a popular idea in a survey may not be urgent if users rarely encounter the problem in real life.

A practical validation question is: “What would we expect to see if this problem is real?” The answer might be repeated support conversations, low completion rates, high manual effort, frequent exports, duplicated work, or consistent feedback from the same user segment. Once the team knows what evidence would support the idea, it can look for signals instead of relying on personal preference.

Validation does not guarantee that a feature will succeed. It does, however, help teams make better decisions with fewer assumptions. When evidence shows that users have a real problem, care about solving it, and are likely to use the solution, the feature has a stronger case for moving forward.

What Outcome Should This Feature Create?

After identifying the problem, audience, and evidence, the team needs to define the outcome: What should change because this feature exists? A feature is not valuable simply because it ships. It becomes valuable when it helps users complete an important task, removes friction, supports a business goal, or improves the overall product experience.

This step helps teams move from building something to creating a measurable result. Instead of saying, “We want to add saved templates,” a stronger outcome might be, “We want users to create repeatable workflows faster, with fewer manual steps.” That framing gives the team a clearer reason for the feature and makes it easier to evaluate whether the solution is working.

Useful outcome-focused questions include:

• What user behavior do we expect to change? For example, will users complete setup faster, invite more teammates, return more often, or finish a task with fewer errors?
• What business goal does this support? The feature may connect to activation, retention, conversion, expansion, support reduction, or customer satisfaction.
• What pain point should be reduced? Look for outcomes such as less confusion, fewer repetitive tasks, shorter workflows, or lower dependency on support.
• What would success look like from the user’s perspective? A user-centered outcome might be, “I can understand what to do next without asking someone for help.”
• What should not change? Sometimes the goal is to improve one workflow without adding complexity, slowing performance, or distracting from core product use.

Clear outcomes also help prevent scope creep. When every proposed addition is compared against the intended result, the team can ask, “Does this help create the outcome, or is it just a nice extra?” This makes prioritization more objective and keeps the feature focused.

A practical outcome statement might look like this: “This feature should help new account admins invite their team and assign roles during initial setup, reducing confusion and making the first session more successful.” It identifies the user, the action, the context, and the expected improvement.

Teams should avoid vague outcomes such as “make the product better” or “increase engagement.” Those goals may sound positive, but they do not guide decisions unless the team defines what “better” or “engagement” means in a specific workflow. A stronger version would explain which users should engage, what action they should take, and why that action matters.

When the desired outcome is clear, the feature has a purpose beyond delivery. Designers can focus on the right experience, engineers can make smarter implementation trade-offs, and stakeholders can judge success based on results rather than opinions.

What Is the Smallest Useful Version We Can Build?

Before building a full feature, teams should ask: What is the smallest useful version that could solve the core problem? This question helps prevent overbuilding, reduces unnecessary complexity, and gives the team a faster way to learn whether the idea is worth expanding.

The smallest useful version is not the same as a low-quality version. It should still be reliable, understandable, and valuable to the intended user. The goal is to deliver the essential outcome with the least amount of scope required. Instead of trying to include every possible setting, workflow, permission, integration, and edge case in the first release, the team focuses on what users need most to complete the main task.

A helpful way to define this version is to separate requirements into three groups:

• Must-have: The feature cannot solve the problem without this.
• Should-have: This would improve the experience but is not required for the first release.
• Later: This may be useful, but it can wait until the team has more feedback.

For example, if users need a way to save and reuse project templates, the first version may only need basic template creation, naming, and reuse. Advanced sharing rules, analytics, template folders, and marketplace-style discovery might be valuable later, but they may not be necessary to test whether users actually benefit from reusable templates.

Teams can also ask whether the feature needs to be fully automated right away. In some cases, a manual process, lightweight prototype, limited beta, or internal tool can validate demand before the team invests in a polished product experience. This is especially useful when the team is still learning which workflow matters most.

Important scoping questions include:

1. What is the one job this feature must help users complete?
2. Which parts of the experience are essential for trust and usability?
3. What can be removed without weakening the core outcome?
4. What can be handled manually, temporarily, or outside the product at first?
5. What feedback do we need before deciding whether to expand it?

A strong first version gives the team room to learn. It should be narrow enough to build and evaluate, but complete enough that users can experience real value. If the version is too thin, users may reject it because it does not solve the problem. If it is too large, the team may spend too much time building assumptions that have not been tested.

The best scoping conversations are not about cutting corners. They are about protecting focus. When teams define the smallest useful version, they make it easier to launch thoughtfully, measure results, and improve the feature based on actual use rather than speculation.

What Are the Costs, Trade-Offs, and Risks?

Every feature has a cost, even when the idea is strong. Before building, teams should ask: What will this feature require, and what might we give up by choosing it? This question helps teams look beyond the visible build work and consider the full impact on the product, the team, and the user experience.

The most obvious cost is development time, but that is only one part of the decision. A new feature may also require product planning, design exploration, user research, QA testing, documentation, customer support training, security review, performance monitoring, and future maintenance. If the feature touches billing, permissions, integrations, notifications, data models, or core workflows, the complexity can increase quickly.

Useful questions to ask include:

• Which teams need to be involved? Product, design, engineering, data, support, sales, marketing, and customer success may all have a role.
• What existing work will be delayed? Building one feature often means not building or improving something else.
• What ongoing maintenance will this create? A feature may need bug fixes, updates, support articles, analytics tracking, and future compatibility work.
• What could make the product harder to use? More options can create confusion if they are not clearly organized.
• What dependencies or technical constraints exist? The team may need API changes, infrastructure work, data cleanup, or third-party integration support.
• What happens if the feature does not perform as expected? Consider how easily it can be adjusted, limited, or removed.

Trade-offs are not automatically a reason to stop. They are a way to make the decision more honest. For example, a feature that helps enterprise customers may be worth the complexity if it supports a clear business goal and does not disrupt the experience for smaller accounts. On the other hand, a feature that serves a narrow edge case may not be worth adding if it makes a core workflow harder for most users.

Risk should also be evaluated from the user’s point of view. Will the feature change familiar behavior? Could it introduce errors in an important workflow? Will users understand what it does without needing extra explanation? Could it create inconsistent experiences across plans, roles, devices, or integrations? These questions help teams identify issues before they become launch problems.

A practical way to frame this discussion is: “What must be true for this feature to be worth the cost?” The answer might involve expected adoption, revenue impact, reduced support burden, improved retention, or stronger product positioning. If the expected value is unclear, the team may need more validation, a smaller first version, or a different approach.

Good product decisions are rarely about whether a feature is interesting. They are about whether it is worth the investment compared with other ways the team could create value. By discussing costs, trade-offs, and risks early, teams can make more responsible decisions and avoid shipping features that create more complexity than benefit.

How Will We Measure Success After Launch?

Before a feature is built, the team should decide how success will be measured. The key question is: What evidence will tell us whether this feature is working? Without a clear measurement plan, teams may rely on opinions, scattered feedback, or launch excitement instead of understanding whether the feature actually created value.

Success metrics should connect back to the problem and outcome defined earlier. If the feature is meant to help new users complete setup, the team might track setup completion rate, time to completion, drop-off points, and support questions related to onboarding. If the feature is meant to reduce manual work for admins, useful signals might include repeated usage, fewer exports, fewer support requests, or shorter task completion time.

Good measurement usually includes both numbers and context. Quantitative data can show what users are doing, while qualitative feedback can help explain why they are doing it. A feature may have strong adoption but still create confusion. Another feature may have lower usage because it is designed for a narrow but important segment. Looking at both types of evidence helps teams avoid oversimplifying the results.

Useful questions include:

• What primary metric best reflects the intended outcome?
• What supporting metrics will help explain user behavior?
• Which user segment should we measure separately?
• What baseline are we comparing against?
• How soon after launch should we review results?
• What signals would suggest the feature needs improvement?
• What signals would suggest the feature should not be expanded?

It is also important to define what success does not mean. A launch announcement, a spike in curiosity clicks, or a few positive comments may be encouraging, but they do not always prove long-term value. Teams should look for sustained behavior that matches the feature’s purpose.

A practical success statement might sound like this: “Within the first 30 days after launch, we expect team admins who use the feature to complete access reviews with fewer manual steps and fewer support requests related to permissions.” This gives the team a specific audience, timeframe, behavior, and improvement area to evaluate.

Measurement should not be treated as a final report that happens after everything is done. It should be part of the feature plan from the beginning. When teams know how they will measure success before development starts, they can design better tracking, set more realistic expectations, and make smarter decisions after launch.

What Happens After We Launch?

A feature is not finished the moment it goes live. Launch is the point where the team starts learning from real use, real feedback, and real operational needs. Before building, teams should ask: What happens after this feature launches, and who is responsible for making sure it succeeds?

Post-launch planning helps prevent a common problem: the team ships a feature, announces it, and then moves on before understanding whether it works as intended. Even a well-designed feature may need adjustments once users interact with it in their normal workflows. Teams should be ready to monitor usage, review feedback, fix issues, and make thoughtful improvements.

A strong post-launch plan should cover:

• Ownership: Who will monitor results, respond to feedback, and decide what happens next?
• Rollout strategy: Will the feature launch to everyone, a beta group, a specific customer segment, or a phased percentage of users?
• Support readiness: Do support and customer-facing teams know how the feature works, where it appears, and what questions users may ask?
• Documentation: Are help articles, release notes, onboarding tips, or internal guides needed?
• Feedback loops: How will the team collect user reactions, bug reports, sales input, support themes, and usage data?
• Iteration plan: What improvements might be considered after the first release, and what evidence would justify them?
• Sunset criteria: If the feature does not create enough value, when would the team simplify, pause, or remove it?

It is especially important to decide how quickly the team will review early signals. Some issues appear within days, such as confusing copy, broken workflows, or unexpected support questions. Other outcomes take longer to evaluate, such as retention, repeat usage, or reduced manual work. A review plan helps the team avoid reacting too quickly to noise while still catching urgent problems.

Teams should also consider the long-term responsibility of maintaining the feature. Every feature adds surface area to the product. It may need updates when the interface changes, when permissions evolve, when integrations are modified, or when customer expectations shift. If nobody owns that maintenance, the feature can become outdated, confusing, or inconsistent with the rest of the product.

A practical post-launch statement might be: “We will launch this feature to a small group of account admins first, monitor usage and support questions for two weeks, review results with product and customer success, and decide whether to expand, revise, or hold the rollout.” This kind of plan creates accountability and gives the team a clear path beyond launch day.

The best product teams treat launch as a learning milestone, not a finish line. By planning for ownership, measurement, support, iteration, and possible removal, teams build features with more care and make better decisions after users begin using them.

Expert Tips & Pro Insights

Building a new feature is easier when the team treats it as a decision process, not just a delivery task. Strong product teams slow down just enough to understand the problem, compare options, and define what they need to learn. This does not mean creating unnecessary bureaucracy. It means asking better questions before committing valuable time to design and development.

Use these expert-level practices to make feature decisions more reliable:

• Write the problem before writing the requirements. A feature brief should begin with the user problem, target audience, evidence, desired outcome, and success metrics. Requirements should come after the team understands why the feature matters.
• Separate user requests from user needs. A customer may ask for a specific button, dashboard, filter, or integration. Treat that request as a clue, not the final answer. The deeper need may be speed, clarity, confidence, automation, compliance support, or better reporting.
• Use evidence from more than one source. Combine qualitative feedback with behavioral data when possible. For example, customer interviews may explain the problem, while analytics or support patterns may show how often it appears. Teams working with technical products can also review guidance from trusted developer resources such as Google Developers when planning implementation, measurement, or platform-specific decisions.
• Define the “non-goals.” Non-goals explain what the feature will not solve in the first version. This helps prevent scope creep and gives stakeholders a clear reason when certain ideas are delayed.
• Plan the rollout before the build is complete. A thoughtful rollout may include a beta group, internal enablement, support documentation, success metrics, and a review date. Public knowledge sources such as Wikipedia or structured data projects like Wikidata can be useful when teams need general background context, but product decisions should still be grounded in their own users and product data.
• Keep a decision log. Record why the team chose to build, delay, reduce, or reject a feature. This creates accountability and helps future team members understand the reasoning behind product changes.
• Review the feature after real usage. A feature should be evaluated based on whether it changed user behavior or improved the target workflow.

A useful rule of thumb: the more expensive or permanent a feature is, the stronger the evidence should be before building it. Small experiments may only need lightweight validation. Large features that affect core workflows, pricing, infrastructure, permissions, or long-term maintenance deserve deeper review.

The strongest feature decisions usually come from teams that can clearly answer three questions: Why this problem? Why this audience? Why now? If those answers are specific and evidence-based, the team is in a much better position to build something users will understand, adopt, and continue using.