What is your general framework and/or process for prioritizing product features?
Prioritization is arguably one of the most important responsibilities of a Product team (and the senior leadership team). Regardless of whether you’re Google or a Series A startup, there are always finite resources and a long product backlog. Especially for early-stage startups with extremely limited resources, the wrong prioritization (and thus the wrong way of deploying your resources) can destroy your business.
It is thus critical to develop the discipline to frequently ask yourself (and make sure you can confidently say “yes”): “Is my team working on the most impactful thing they could be working on right now?” Below is a general framework I’ve found success with when it comes to roadmap planning and prioritization.
Top-down vision & strategy, bottoms-up (and sideways) ideation. The best product ideas come from your team (and not just the Product team). To empower your teams without creating misalignment, the company leadership needs to articulate a clear long-term vision and strategy so teams can design different paths towards the same north star. Practically speaking, I believe a good cadence for a early/growth stage startup is to establish a 3–5 year vision, review the strategic focus annually, and do a “no stones left unturned” ideation every six months.
“Bang for Buck” analysis with a common currency. The key for prioritization is to evaluate every idea objectively, and objectivity has to come from a company-wide KPI that can be used to measure impact across different types of initiatives (one I’ve found success with is profit LTV as it captures growth/retention as well as unit economics/cost benefits). For each initiative, the Product team should do a quick back-of-the-envelop triangulation around impact and collaborate with Engineering teams to establish high-level estimates. The math will be rough, but what matters is that these initiatives can be compared apples-to-apples. This step requires a fair amount of heavy lifting, but going through this exercise will often reveal unexpected outcomes and help correct existing biases.
Break up the footlong sub. Be critical about the versioning of your feature as you don’t always have to ship the footlong sub in one go. Especially for startups with a small team, time-to-market and the ability to make immediate business impact (even through only a subset of the feature) need to be explicitly considered vs. the other pros & cons of shipping a larger bundle (e.g. sales cycle/marketing messaging, training overhead, QA cycle, user experience, technical tradeoffs). If you decide to break up the footlong sub, consider what the smallest release could look like that can 1) make immediate business impact, and 2) help you validate/invalidate a key hypothesis that would help you deploy future resources more efficiently.
Set aside time to delight your users and invest in your tech stack. There are certain things that are the “right things to do” but are hard to quantify impact — e.g. visual design updates, “experience features” such as a whimsical empty state that would bring your users smile, and various tech debt you’ve accumulated over the years because you‘ve always biased towards shipping fast. One effective way to chip away on these long-term investments is to set a resource allocation target (e.g. 10% bandwidth on engineering investments, 5% on user delight) so the teams have the room to make progress without taking their eyes off the ball on shipping features.
Are you a founder working on the first draft of your product, looking for investment and advising? Check us out at co-op.vc
