The Ten Questions I Always Ask Myself as a Product Manager - ProductFTW #57

Recently, I was mentoring a new product manager, and I realized that every time I receive a request, whether it is a new feature, an enhancement, or even a bug fix, I instinctively run it through a mental checklist of ten questions. These questions help me decide whether it is worth investing more of my time into and, more importantly, whether it is worth the business’s time.

Product management is about making trade-offs. Every decision has an opportunity cost. If you say yes to one thing, you are saying no to something else. Having a structured way to evaluate requests helps avoid wasted effort and ensures that your time is spent on the most impactful work.

Here are the ten questions I always ask myself before deciding to invest in a new request.

1. Will this feature be used by more than one customer?

The first thing I want to know is whether this request serves one customer, multiple customers, or all customers. If it is something that only benefits a single customer, I need to consider whether it is truly a one-off request or if it represents a broader need.

A good rule of thumb is that product development should focus on scalable solutions. If a request is too specific, it may be better suited for a custom implementation or a support workaround rather than core product development.

2. What will the impact be if we enable it?

A feature might be interesting, but I need to understand why it matters. Will it help users achieve their goals faster? Will it generate revenue? Will it improve retention?

If the impact is unclear or minimal, it is probably not a priority. Every request should tie back to a measurable outcome, whether it is business value, customer satisfaction, or competitive differentiation.

3. What will the impact be if we do not enable it?

Just as important as knowing the potential benefits of a request is understanding the consequences of not doing it. Will customers churn? Will it cause frustration? Will we lose a potential partnership?

Sometimes, the urgency of a request is not about the value it adds but about the risk of not doing it. If failing to implement something could damage trust, cause operational issues, or create compliance problems, it might move up the priority list.

4. Does this feature make our product more competitive, or are we just keeping up with the market?

There is a difference between a feature that makes the product more competitive and a feature that just keeps us on par with competitors. Both can be important, but they should be weighed differently.

If we are falling behind market expectations, that is a problem. A lack of expected features can make us look like a weaker option in the market. However, if we are just copying a competitor’s feature, we need to ask whether it is worth the effort. The best investments are in features that set the product apart, not just maintain feature parity.

5. How does this affect existing users? Does it create friction or improve usability?

A product change can have unintended consequences on the user experience. A new feature might solve one problem but introduce friction somewhere else.

I always consider how this will feel from the user’s perspective. Will this make their workflow easier or more complicated? Will it introduce new confusion or frustration? A feature that technically works but creates user friction is not a good investment.

6. Does this align with the product strategy?

No matter how compelling a request might be, if it does not align with the long-term product strategy, it is likely a distraction.

Product roadmaps are built around core business objectives, and every new investment should fit into the bigger picture. If something feels out of place, I ask myself whether the strategy needs to evolve or if the request is simply not a priority right now.

7. Is it a quick win or a major lift? If it is complex, does it justify the effort?

Every team has limited resources. That is why I always consider the level of effort required to implement something versus the expected value.

• If something is a quick win and delivers clear value, it is usually worth doing.
• If something is a major lift, I need to weigh it against other priorities.

Some complex projects are worth the investment, but if a request is a high effort with low impact, it is an easy decision to say no.

8. If we build this, will it scale well across partners and future iterations?

A feature might solve an immediate problem, but I always ask whether it will scale over time.

• Will this feature be flexible enough to support future use cases?
• Will it require ongoing maintenance and support?
• Will adding this feature create technical debt that will slow down development later?

A feature that only works in a narrow context may not be worth the investment unless it is absolutely critical.

9. Will this create risk for us? If yes, how much risk, and can we control it?

Some requests introduce risk. That risk could be security concerns, performance bottlenecks, or unintended user behavior.

• If the risk is high but manageable, I ask whether we have the right controls in place.
• If the risk is too unpredictable, it may not be worth pursuing.

Understanding risk tolerance is a key part of making informed decisions.

10. Will this require a legal or compliance review?

Because I work in fintech, legal and compliance considerations are always top of mind. If a change has regulatory implications, we need to bring in compliance teams early.

Legal and compliance reviews can introduce long feedback loops, so the sooner we identify the need for their involvement, the better.

This question might not be as relevant in every industry, but for regulated businesses, failing to account for compliance early can lead to delays, legal issues, or even blocked releases.

Why These Questions Matter

Every product manager faces constant requests from customers, stakeholders, and internal teams. Saying yes to everything is impossible, and without a clear decision-making process, it is easy to get pulled in too many directions.

These ten questions help me filter requests efficiently. If a request does not hold up against these questions, it is probably not worth the investment. If it does, it allows me to move forward with confidence.

At the end of the day, good product management is about focus. It is about knowing which opportunities are worth pursuing and which ones are distractions. The best product teams are not the ones that build the most features. They are the ones that build the right features.

Whether you are a new product manager or have been in the role for years, having a structured way to evaluate requests can help you prioritize with clarity, push back when necessary, and ensure that every decision contributes to meaningful progress.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Product Management Leadership & Career Guide — ProductFTW's collected essays on the PM role, leading without authority, hiring, and getting hired.