This is a frequent question from every product manager. Whether is a new product that’s is being created now, or a fully operating product full of suggestions from clients and users, how to prioritize, that is, how to decide what to do first?
There is a great number of techniques. I’ll talk about a few here and, in the end, I’ll tell which one is the best. I only ask you not to jump to the end of this chapter so you won’t ruin the surprise… 😛
One of the simpler ways of prioritizing a roadmap is making an analysis of all items, seeking for estimating: the value (benefit) of each one for the business and for the users, and the cost of implementing each item. With these data in your hands, it is possible to even build a graph with two axes and put each and every one of the items in it based on the value and on the cost. The idea is to always prioritize what has the bigger value and lower cost, for the benefit will be obtained more quickly.
Kano Model was created by professor Noriaki Kano, from Tokyo University, to classify the items of a product based also on two dimensions, the need of an item and the excitement that it provides to clients. With this, it is possible to classify the items into three types: basic; satisfies, and delighters.
For instance, in a car, the wheel is a basic item, for there is no car without wheels. The sunroof is a satisfier item if your client does not consider it valuable. Being very silent is an item that delights a client that appreciates it. The recommendation is to have all basic items, some satisfiers, but do not leave some delighters out if you want to positively impress your client.
When I arrived at ContaAzul, I came across another prioritization method adopted by the product team, RICE. RICE stands for Reach, Impact, Confidence, and Effort. The first three items of the matrix are scored and, in the end, divided by the last.
Reach refers to how many people that task will reach over a given period of time, which should be the same for all features being compared. Impact estimates how many people will be impacted (use 3 for a massive impact, 2 for a large impact, 1 for a medium impact, 0.5 for a small impact, and 0.25 for a minimal impact). Confidence addresses how confident you are about your estimates (choose from 100% for high confidence, 80% for medium, and 50% for low). In Effort, enter how many person-months the task will take to complete with a minimum of 0.5, ie one person per half month.
The mathematical calculation is very simple:
RICE = (Reach x Impact x Confidence) / Effort
Feature Sequencer was created by Paulo Caroli, from ThoughtWorks, to plan a product based on deliverables and its features. The sequencer rules, such as three cards per line, foster the prioritization conversation.
According to the Lean Inception: How to Align People and Build the Right Product book, the Feature Sequencer helps you organize and visualize the features and their relation to the deliverables. The sequencer organizes and plans the product releases beyond the first deliverable. Typically, teams using the feature sequencer will dazzle the product evolution via a clear understanding of the features contained by each deliverable, and the release order.
The previous image has a sample feature sequencer; each feature is represented by an index card. The post-its on the right-hand side represent the deliverables.
The idea is kind of like the Kano analysis: classifying items of the roadmap according to the parts of a tree. Roots are the infrastructure; the stalk provides support; the branches are the different paths in which you can put your product in; the leaves are the features themselves, and the flowers and the fruits are the features that are going to delight the customer. Every product has to have roots, stalk, and some branches with their respective leaves, but it’s important to always add on some flowers and fruits in order to make your product delightful.
In this technique, you make everyone play a game. You show all the items in your roadmap and set a value for each one based on how much is going to cost to build it. Then, invite some clients and tell them they have X to spend. This X must be substantially less than the sum of the value of all your items.
With this X, each client has to buy the most important features and, as the money is limited, everyone is forced to make choices such as “Do I take these two features or trade them for this more expensive one?”. It is a very interesting exercise and provides good knowledge of client behavior.
UserVoice is a suggestion system that you can put in your product. With this, your user will be able to make suggestions about it, and will also be able to vote for suggestions from other users. You can still limit the number of votes, forcing them to make choices, like in the previous method.
Jason Fried, the founder of 37signals, now renamed as Basecamp, said in his book Getting Real[ that in his company the option was to prioritize based on remembrance. They receive several suggestions every day and simply decided not to write them down so they won’t spend time counting and classifying them.
As suggestions come up every day, they hear them every day. From time to time, they get together and discuss the suggestions they remember, and these are the ones that are approached and eventually prioritized in the product’s roadmap.
As you can see, there are many ways of prioritizing a roadmap, all very useful. In other words, what we can conclude is that if there are so many ways of prioritizing a roadmap and if all prioritizing ways can be useful, it means that prioritizing a roadmap is not an exact science.
We are eager to find a prioritization method that justifies our choices. However, every time this method fails in a certain item that we are sure it is best to do it before (or after) then the method tells us to do, we end up tempted to follow our certainty, ignoring and not following the method.
However, there are several roadmap prioritization techniques and methods, and the best method is common sense. That is, the ability the product managers have of analyzing the available options and, by using their empathy, they prioritize these options taking into account the company’s goals and the users’ needs.
During the lifecycle of your product, you will certainly meet requests of new features coming from clients (or the commercial team) that, explicitly or not, come with a threat that if you don’t build this feature you will lose them. On the other hand, if you meet this demand to the detriment of all roadmap planning already made, you are risking to delay the delivery of important features to the rest of the clients and to the strategic goals of the software product owner.
The answer to this question depends a lot on your product and your client base. I’ll explain this answer with an example.
At Locaweb, we have two e-mail marketing products. One of them is called ** Locaweb’s E-mail Marketing** (very original name, hum?), and the other one is the All-In Mail. To understand the dimension of each product and the type of client that each one of them attends, here are some figures.
In this table, we can see that although the E-mail Marketing from Locaweb has 75 times more clients than the All In Mail, it sends only 16,7% of the total messages sent with All In Mail. In other words, Locaweb’s E-mail Marketing holds much more clients than All In Mail, but they are small clients that use the product very little compared to All In Mail’s clients.
For that reason, the product manager of Locaweb’s E-mail Marketing cannot afford to attend to special requests. The manager cannot favor the request of one single client to the detriment of the other 29,999. The product manager in this case must be concerned with implementing features that attend to as many clients as possible. And the product manager of All In Mail not only can but must pay full attention to special requests. There are a few clients, but all of them are special and demand customized attention.
When we talk about prioritizing a roadmap, one thing that happens is that we end up answering to every request, from everyone. That is, everything is important because everything is added to the roadmap, and then the less important things are postponed. The person who requested has the confidence that “it’s in the roadmap”, although it was pushed upfront on the line, and has good chances of being pushed even further if some more important item comes up.
The product manager ends up saying yes to requests he/she gets for several reasons:
In spite of all the reasons we saw here, in order to say yes to each and every feature request, a product manager has to learn how to say NO.
Saying NO seems difficult, but not if you have your product goals very clear, that is, which company goals your product must reach, who is your main client and what is the problem of this client you are trying to solve, you’ll have the necessary arguments to say NO to certain demands.
Be kind to the person who is bringing the demand and say something like:
How to say no
Your suggestion is interesting and I can see why you are giving them. However, let me show you what we have already planned in our roadmap, and which are the goals of each item in it. For this reason, we will not be able to pay due attention to your request right now. Remind me in the future so we can talk about this again, ok?
Pass on the responsibility for remembering the conversation again in the future for the person who is requesting the new feature. If he/she does not remember, it is because his/her request was not that important. If he/she remembers, evaluate the request again and, if necessary, say NO again.
I mentioned earlier that if you have a B2B product focused on bigger customers, the product manager “must pay full attention to special requests. There are few customers, but all of them are special and demand customized attention. The product manager must be careful and not implement features that will be used by only one customer. However, requests from one customer, especially the bigger ones, will always be a priority in this scenario.”
So this means that the product manager should do everything that big customers demand?
The short answer is *NO! You are still managing a product, so two important aspects of product management still apply:
The longer answer is no, but you’ll still have to manage the special requests. There are some techniques that can help you deal with these special requests:
New special requests come up during the sales process. Each of these special requests will take time from the product manager as well as the product development team. The team needs to understand the special request, the underlying problem and design solution options that can be used with other customers. This will take time from the product manager and the team.
At a certain point, the team will use the above-described techniques to cope with the special requests in a scalable way. As soon as the team starts using these techniques, the need to interact with customers for each request will probably persist or even increase. The sales team will ask the product manager to have meetings with the customer and help them show the customer what are the technical options available in order to address the request.
The first step is to train the sales team. However, this won’t be enough. The product manager will continue to be asked to join meetings to answer technical questions. To help with this issue, we should create a new role, the technical sales, also known as a sales engineer or pre-sales, someone with a technical background who will engage in technical discussions with the customer during the sales process.
Sometimes this role, since it has the sales word in it, is placed under the sales leadership. It’s a possibility but can lead to misalignment of incentives. Under sales leadership, the incentive is the number of sales. So, if a tech seller is taking too long to design the solution, and other requests get delayed, a new tech seller is hired, increasing headcount and, consequently, the cost of selling. An alternative is to place this position under product management leadership so the focus is on sales enablement, i.e., to provide the sales team with the needed tools to conduct sales without the need for a tech seller.
Supposing everything goes well with the negotiation and the customer decides to buy your product, if there are customizations to be made, additional work is required, no matter if it will be through modules, through advanced configuration, and/or through integration. This work may end up falling into the product development team backlog, which is not ideal since this work is specific to address a certain customer request, while the product development team should be working on things that could be used by the majority of customers.
To help with this issue, we should create a second role, called professional services. A person with this role works on this type of project, setting up a new customer using the customization techniques from the product (modules, advanced configuration, and/or integration). They should be people with technical skills able to do the customization work needed to set up the new company. Professional services can be done by a team within the company that offers the product and/or by third parties. For instance, to implement SAP, Salesforce, or Zendesk, you can choose to use professional services from them or from certified third parties that have knowledge and experience in implementing and customizing their software in many customers. This work is normally billed as a setup fee.
We saw many techniques to prioritize a roadmap. Prioritizing a roadmap is not an exact science and we learned that the best way to prioritize a roadmap is pure and simple common sense, i.e., building a roadmap that aligns the company’s goals and objectives while solving a problem or fulfilling a need of clients and users. We also learned how to say no to prioritization requests and what is and how to deal with special requests.
Dealing with special requests may be a need of your market, especially if you are in the B2B space with bigger customers. It is possible to build a product that fits these special requests without building a “frankenstein software” product. In order to do that, the product manager and product development team should use one or more of the known techniques to deal with special requests, modularization, advanced configuration, and integration. Having these techniques in place won’t probably be enough, since the sales team will still need help in order to present the options to the customer and, after the sale, to implement them. Then two new roles come up, that should be close to product management: technical sales – or sales engineer – and professional services, which could be internal, could be done by third parties or both.
Next topic: Data!
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:
You can also acquire the books individually, by clicking on their titles above.
I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.