How to Decide What to Build and What Not to Build

Deciding what to build — and what not to build — is the core of product management. The trap most candidates fall into is starting with what they built and listing features or specs. The actual job is to start with why: why this product or feature, for which customer, and what problem it solves.

You must think about the scalability of the problem. Is it a pain point that affects many users? Is it a problem that can generate significant value or revenue if solved? If you cannot justify the "why," you are building noise, not a product.

Start with the customer and the problem

The first question you must always answer is: Who is this for, and why does this customer need it?

This is not just a formality. It drives everything else.

• If you build a feature that only a handful of users care about, it will not move the needle.
• If the problem is not painful or frequent, the feature will be ignored.
• If you cannot articulate the problem clearly, you will not be able to prioritize or measure success.

What I tell PMs is: start your answer with the customer and the problem, not the solution. That is the entire profession in one line.

What makes a problem worth solving?

Not every problem deserves a product or feature. You need to evaluate the problem using several criteria:

• Relevance to many users or just a few? The bigger the affected user base, the more critical the problem.
• Frequency of usage. How often will users encounter this problem or use the feature?
• Competitive positioning. Will solving this problem strengthen your position in the market or differentiate your product?
• User empowerment. Does this solution give users a "superpower" that makes other tools obsolete?
• Complexity and effort. Is the implementation effort reasonable compared to the expected impact?
• Growth potential. Can this feature or product open up new user segments or revenue streams?

These criteria help you separate good ideas from distractions.

A five-step process to decide what to build

I recommend a structured approach to product decisions. This is a general pattern that works across company stages and product types:

1. Identify market trends, customer demand, available resources, and feasible options. You need to know the landscape before committing.
2. Brainstorm with your team — product, design, engineering, business — to plan the product design, development approach, and execution.
3. Measure scalability by estimating the resources needed and the potential user impact. This helps avoid over-investing in niche features.
4. Prepare the team and resources by resolving challenges upfront — dependencies, skill gaps, data needs.
5. Execute by bringing the plan to action with clear milestones and feedback loops.

This process is iterative. You learn and adjust as you go.

The trap of feature dumping

A common failure mode is "feature dumping" — adding features just because they sound good or competitors have them. This dilutes your product, increases complexity, and confuses users.

What I tell PMs is: if you cannot answer why a feature matters to the core user and how it moves the needle, you should not build it.

Good PMs say no more often than yes. Saying no is hard. You will face pressure from sales, marketing, and leadership. But the discipline of saying no keeps your product focused and your team efficient.

Growth potential vs complexity trade-off

Not all features have equal impact or cost. You need to balance growth potential against implementation complexity.

For example, a feature that unlocks a new user segment might be complex but worth it. A feature that slightly improves an existing flow but is very complex might not be worth the effort.

Use data and user research to estimate these trade-offs.

How to answer this question in interviews

When asked "How do you decide what to build and what not to build?" your answer should cover:

• Starting with the customer and the problem. Who is this for, and why do they need it?
• Criteria you use to evaluate the problem and solution: user impact, frequency, growth potential, complexity.
• A clear process you follow to identify, brainstorm, measure, prepare, and execute.
• Awareness of trade-offs and the discipline to say no.

Avoid generic frameworks or buzzwords. Instead, show your thinking and how you apply it in real situations.

Field exercise: Prioritize your product ideas

The uncomfortable reality: you must say no

Saying no is the hardest part of product management — especially in India, where stakeholders expect quick yeses.

But if you build everything, you build nothing well.

Talvinder often says: The actual job is to make trade-offs and say no more than yes.

This is what separates PMs from project managers.

Where to go next

• If you want to learn how to break down problems and find creative solutions: Product Sense
• If you want to practice prioritization frameworks and trade-offs: Prioritization Skills
• If you want to improve stakeholder communication: Stakeholder Management
• If you want to understand the full product lifecycle: From Idea to MVP

PL alumni now work at Flipkart, Razorpay, PhonePe, Swiggy, Amazon, Microsoft, and many more.