Whether you are a startup founder or a product manager, you can't escape the perennial challenge of prioritizing your product development. Perhaps like me, you are plagued with dilemmas that force you to choose from improving an existing feature, strengthening your tech infrastructure or going after an innovation that will take more time.

In a world where every company has finite resource, where every person gets the same 24 hours in a day, the ability to prioritize and allocate your efforts into projects that will generate the highest return is a superior advantage. On the other hand, if you can't prioritize well, you could lose the opportunity to create value for your users and risk wasting weeks of your team's time on products that do not take your business forward. 

Product prioritization is not easy. It's the impossible calculus of time, experience, behaviors, business impact and market dynamics, with more unknown variables than known. But I like to think it's a worthwhile art. Here's what I've learned so far:

1. Be clear on what metric you are trying to move and by how much

First, be explicit on your product mission and the success metric of that mission. Are you trying to increase traffic, improve engagement, or conversion in a specific funnel? This will help your team define clear boundaries of the problem space you are trying to solve. Don't go after all metrics. Trying to go after multiple metrics would quickly dilute focus and obscure the prioritization of what work is more important. 

Second, it is just as important for you to determine the scale of impact you are trying to achieve. If you are aiming a 5% improvement, but the proposal you have at hand can only bring a maximum of 0.5%, you ought to re-think your proposal and go for something more impactful.

2. Start with your user goals

A well-written, thoughtful user problem statement goes a long way. What is the user pain point you are trying to solve? Who is the user you have in mind - all users or a particular segment of users? Can you validate the user pain point with data? What is a successful outcome for the user? 

Don't start with a specific solution in mind - "Let's make this new button to do this cool thing" - and reverse engineer the user problem statement because that could lead you building a product that the user never really wanted. 

Starting from user goals will also prevent you from mindlessly replicating market benchmarks. Resist making the assumption that something that exists in our competitors' platforms is always worth developing. We can't imply that our users or our platform will benefit from the same set of features. 

Finally, avoid using a business goal as substitute for a user problem statement. It goes without saying that every business aspires for more growth and revenue. Wishing your revenue grows by X% rarely does anything, but empathizing with your users and developing great product experiences will bring you closer to achieving your business goals.

3. Understand the difference between solving deep user pain points vs. creating nice-to-haves that no one urgently needs or willing to pay for

I learned that users are only willing to pay for something or adopt new behaviors when our product solves their pain points. Solving pain points - emphasis on the word "pain" - means removing frustrations or catering to an unmet desire. This can be a hard distinction to make because we can conflate solving pain points with making a product more seamless. 

Surely, countless product development has been done in the name of "seamlessness", but increasing seamlessness will not guarantee that your users would do anything different. Your users may be grateful that you reduced 1-2 clicks in their flow during user testing, but that gratitude may not be enough to make users want to scroll more on your platform or create another purchase order or register for an add-on service.

Not every inconvenience is a pain point. Understand your users' behavioral thresholds and willingness to pay: "If we do X, will this be enough to make you want to do Y?", "Is Z feature good enough for you to pay X% more?" This way, you can prioritize delivering change that your users find meaningful.

4. State clearly what you are willing to give up

Just as you need to be clear on what's most important for your business now, you need to be clear on the trade-offs you are willing to make. Trade-offs could mean delayed timelines on a parallel project or deprioritized developments. Are you okay if we only deliver feature X in October? Are you okay with a tech debt persisting for another month?

If you want to be a trustworthy counterpart, especially for tech, and maintain the integrity of your prioritization, you should honor your plan and its implications. Once you commit to a list of priorities, you are also committing to a list of things to not do. Avoid making frequent, last minute changes because that undermines your prioritization process and disincentivizes your team from being thoughtful about future prioritization.  

5. Prioritize not just for your team, but also for the company

Step back and align to the big picture. Get input from your tech and business counterpart. Is your innovation aligned with the overall company direction? Keep an eye out on cross-product synergies and fine-tune your prioritization in a way that can amplify the company's existing initiatives. Usually, there is diminishing return on mature products and the company is better off when we shift resources from more stable products to areas that need more development.