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… 😛

Value versus effort

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 Analysis

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.

RICE

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

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.

Product tree

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.

Buy your features

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

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.

The one you remember first

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.

The best prioritization technique

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.

What to do with special requests?

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.

What to do?

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.

The problem of saying yes to everything

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.

Why does this happen?

The product manager ends up saying yes to requests he/she gets for several reasons:

• Needs to please everyone: this is a very common problem of product managers, the need of pleasing everyone. When product managers see that the answer “I’ll put it in the backlog” calms down people who are requesting something, they start to use this answer indiscriminately. Then, the roadmap will become huge and very complex to manage. In addition to that, when people realize that being in the backlog doesn’t guarantee that it will be done soon, they won’t be happy… :-/

• The data show that we must do: more and more I see companies focused on making decisions exclusively based on data. Therefore, soon we can be replaced by algorithms that will make all decisions, since it is enough to make them all based on data. It happens that data are not always correct. They can be insufficient, or even wrong. Another problem of decisions based in data is the risk of falling in a great place. The suggestion is to use data as one of the inputs to make a decision, but not forgetting the qualitative data, your intuition and your judgment.

• But it is such a small feature: every feature, as small as it is, will imply in more code and more interaction. More code means code complexity; as the code gets more complex, it is more difficult to maintain it. More interaction means more complexity for its user to work with, that is, more chances of offering a bad experience to the user. No feature is so small for not bringing code and interaction complexity, so think carefully if this additional complexity will bring benefits for your user and for the software owner.

• The client requested and, if we don’t build it, he’ll leave: this is the moment of making tough decisions. If you want to please all your clients, you’ll end up pleasing none of them. You have to choose to whom you are building your product. A product cannot have more than two or three primary personas. By the way, the recommendation is to have only one primary persona; having two or three will be quite difficult to manage. If the client’s request does not attend your primary persona, you have to have the courage to say no.

• We can always turn this new feature into one more option in the configuration: one more time, we are creating pointless complexity. As we said, every feature implies in code and interaction complexity. Putting all new features as options to be configured in a set up screen will turn this screen into something very difficult to its user.

• Our competitors already have it: this is a very common mistake, to base yourself on competition and not on your client/user. Remember: a product manager has to worry about making the software meet the goals of the company that owns it, at the same time he/she solves a problem or fulfil a need of the clients. It is important to know what the competitor is doing, but if it has nothing to do with your company’s goals, nor the problems or needs of your client, then you don’t have to do the same.

• The boss wants: there are bosses and bosses. If your boss is extremely up to date regarding the clients, it is important to listen. But if your boss wants a certain feature just because he/she saw it in some competitor, or someone told him/her to do so, you should remind him/her of the company’s goals and the problems and needs of your clients that you are trying to meet with your software product.

Learning how to say NO!

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.

Dealing with B2B customers’ special requests

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.”

How to manage these special requests

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:

• Demand normally comes in the shape of solutions, and big customers can be quite incisive describing the solution they want. It’s the product manager’s job to understand what’s the underlying problem that made the customer request that specific solution. Quick tip: ask why the customer needs that solution and what she will do as soon as she gets that solution. This will give you lots of insights on the customer’s problem.

• You are managing a product, not a tailor-made software. If you implement each and every feature request from customers, you’ll be building a tailor-made software for each customer or, what’s even worse, a “frankenstein software” product.

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:

• Modularization: if you are able to build your product as modules that work together in different combinations to deliver different types of solutions, this will enable your sales team to mix and match the modules to fit the needs of your customers. And whenever a new feature request comes, and you figure out the underlying problem and decide to build a solution for that problem, you can build it as a separate module. You can even charge this customer for the development of this new module. Charging a customer for the development of a new solution, even considering that this new solution can be offered to other customers, is a good way to test the real need of this customer. If he is willing to pay you to deliver this solution, he really needs this solution and trust you to build it. SAP is a good example of modular solutions.

• Advanced configuration: another way to customize your product without making look like a “frankenstein software” product is through advanced configuration. For instance, for a certain customer, feature X can be delivered as the sequence of step A, step B and step C. For another customer, that doesn’t want feature X, but needs feature Y, it can be delivered by the sequence of step C, then step E, and you turn off feature X for this customer. Depending on the complexity, it is possible also to deliver this advanced configuration through programming languages. Some examples are, again SAP, with its ABAP (Advanced Business Application Programming) and Salesforce with Apex, which enables developers to add business logic to most Salesforce system events, including button clicks, related record updates, and Visualforce pages.

• Integration: another common need from big companies is to have your product integrated with other products they already use. For instance, let’s imagine your company provides ecommerce solutions. Your customer hired your ecommerce product and they will have all of their product catalog, and also data on customers and their purchases in your ecommerce product. This big customer will certainly ask you to integrate your ecommerce solution into their ERP, so they can invoice customers and manage their inventory. This integration can be done in many ways, completely manual through re-typing of data, through file exchange or using an API integration. The best solution is through API, since it provides an error-free and real-time solution for the data integration between systems. For this reason, it is very important that your product has APIs with the endpoints needed to connect with other systems.

Technical Sales (or Sales Engineering)

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.

Professional Services

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.

Summing up

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!

Digital Product Management Books

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:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

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.