Everything is a prioritisation problem

When it comes to building a product, everything is a prioritisation problem.

We might be building things right, but are we building the right thing?

The journey of prioritisation begins way before the actual process of prioritisation starts.

I would start by asking these key questions to the product leadership team—What does the future state look like? — Vision. What are we trying to achieve? — Mission. What’s our plan to win? —Strategy. How are we measuring progress towards the strategy? — Goals. What are we building to realise the vision? - Roadmap. Once these fundamentals are covered, I would work my way up from there.

I also keep a check on how grounded these are on customer insights. Are we basing our strategy on a one-time discovery activity, or do we have continuous cycles of user research? This ensures that the prioritisation is well calibrated to the latest snapshot of user needs in a dynamic environment.

With this foundation in place, I would proceed to chalk out the current user journey and the expected user journey with the team. While doing so, I consider three key aspects: What do users feel? What do users think/say? What do users do?

I then map out the opportunity solution tree tied to the key goals and business outcomes. For instance, during our discovery, we might uncover that users:

• Struggle to understand the product’s value during onboarding
• Feel frustrated with the time it takes to complete a key action
• Believe that their feedback goes unheard

These insights then become a springboard for feature ideation, prioritisation and subsequent next steps. Before any feature makes it to the development pipeline, we ensure that it aligns to the business outcomes and addresses identified user needs.

While doing so, I ask these key critical questions: Does this feature drive us towards a specific goal? What assumptions are we testing with this feature? Are we building this feature to test assumptions, or testing assumptions to inform the build? These questions act as pickaxes preventing the team from falling into the trap of becoming a ‘feature factory’.

Only after we clear this checkpoint, I proceed to the prioritisation phase. I personally approach this with four levels of increasing fidelity.

Level One — User Impact

Features that affect existing users take precedence over those impacting potential users. If there are business critical flows that affect existing users, they’re prioritised over everything else (eg. payment flows)

Level Two —Impact vs. Effort

I quickly eliminate features that are low impact and high effort.

Level Three — RICE Scoring

I then proceed to evaluate features based on four criteria: Reach- How many users will this impact? Impact- How significantly will it affect those users? Confidence- How certain are we of the estimates? Effort- How much work will this require?

Level Four — A more detailed RICE

Especially for the high impact, low effort features, prioritising the most important work to do this week might be a bit more tricky to gauge with just a RICE score.

For this purpose, I do a more detailed RICE estimating the org costs, development time, and other relevant metrics, helping me prioritise what needs to be built.

While continuing to allocate development effort, I also conceptually categorise the effort into three different buckets: Feature flags, bugs and Experiments. In this way, I try my best to establish a balance between building and learning. 

This classification is encouraged in startup environments where the building and learning loops are faster