As a founder of an early stage startup you need to be able to wear many hats, do many things. Yesterday you had to be a UX Designer, today a Product Manager, tomorrow a Product Developer, day after tomorrow a Marketeer and so on.

Adelina Peltea, the co-founder of the startup Splinter.me – aiming to improve the recruiting business (profiled on Romanian Startups too), put together a prioritization map for product development in startups.

You may be needing this map for when time comes to be a Product Manager (or have someone who wants to take on this role).

The article below is reproduced with her permission (published originally on her blog).

*************************
At splinter.me we are currently in public beta. A few months ago we did our research and then designed the whole product with all its features on a mindmap. So we had a clear vision of the product to be launched (validated qualitatively) and very limited resources to build it. The investment would only let us survive a few months, time in which we need to do product development plus customer development. We need to get to quantitative validation, to get promising metrics and to get a decent amount of users because our platform even fully developed would not work without data. So with a team of three people (out of which only two with technical skills) and a countdown of aprox. 5 months until “prove awesomeness to continue or die” we started…

And then came the times of confusion: how to prioritize the huge amount of things we were planning to build, bugs we needed to fix, more customer feedback etc. After finishing our first sprint, having a few features launched, we were preparing for a team meeting to decide what goes into product development next.

If not prioritized right, we risk not getting the best results along the way and compromising the ability to adjust resources to the most productive elements.

After an intense research on how to prioritize, I came up with a bunch of great advice from experienced people and a few models (the Kano model, the build-measure-learn model from Lean Startup etc.). I tried to combine all the inputs and make it as visual as possible.

Below it is the outcome that we started now experimenting with and that I want to share with you, thinking that there must be many startup founders that could need such a product development prioritization map.

A few explanations:

1. Features and bugs related to basic needs will always have higher priority than those related to all performance needs. This comes from the Kano model. There are some elements that users need extremely, without which the product would not be functional. These can be things like proper signup/ signin, secure payment etc. However, keep in mind that satisfying these needs don’t increase the satisfaction with your product. They are just mandatory, even unstated needs.

2. The performance features needed to be developed (preferably based on customer research and competition research) should be assigned to business goals. The best is to choose a timeframe for the next sprint and define maximum 3 business goals that are important in that period, with their related metrics and KPIs. Features related to the most important business goal will have higher priority than those related to secondary business goal and so on.

3. For each business goal, the related features to be build are prioritized according to the impact/ effort ratio (or if you want, you can use the diagram with two axes). By impact, I mean impact the feature has on increasing the chosen metrics assigned to the business goal. Those features with a very high impact and low effort or cost (time, people) come first. Those with high impact and high effort or cost come second. Low impact with low effort could be worth giving a try as a third priority. Low impact and high effort should be discarded.

4. After building the basis of the prioritized features, before improving them and fixing bugs the team was to actually measure the impact. If you built features based on qualitative feedback and your estimations, now it is time to check your metrics and see quantitative results. If they didn’t score as expected in your prioritization, you need to rearrange them. With the new order after measurement, it is time to improve the features and fix their bugs. It is obvious now which improvements/ bugs for which feature deserves first your attention and so on.

5. If you have more bugs related to one feature, you prioritize them depending on their severity (how much they affect the performance of the feature) and their frequency (how many users are affected by the bug, or which segment of the users is affected). Higher bars mean higher priority.

So during your next team meeting, define the business goals and features priority for the next timeframe. Print the map and put it in your office. Whenever the development team encounters bugs and improvement request they can realize quickly which ones have priority.
*************************