Select the priority of the user request
  • Transfer
This text has already been published in the English section. However, I thought that reading and commenting could be more convenient in Russian.

It doesn't matter if you are an experienced product manager, or just at the beginning of your career, you will always keep in mind a large list of requests from your customers. What needs to be done first of all, how to handle these requests?

Prioritization of requests is based on several principles. The basis is the compliance with the requirements of the product strategy and the profile of the client. For example, if your software is focused on small organizations, then doing the integration with SAP should not be the thing that you will do first.

But which part of your backlog should be user requests? If the answer is 100%, then this is not quite the right answer. Perhaps it looks weird, then it is.
If you do not like to read long texts, the answer is: if your product is mature, and you have not been paying much attention to user requests for a long time on the market.

Let's take a look at where your product is located. For this, we will use two graphs: S- technology curve and product life cycle.

S-curve technology shows how much effort you need to make to get a result, depending on the maturity of the technology. For example, machine learning, when properly applied, gives excellent business results with reasonable resources. On the other hand, the classic workflow systems can no longer surprise, and it is difficult to squeeze something truly amazing from them.

New technology brings new ways of working. For example, in scanning and recognition software, the classical technology uses template libraries for classification. New technology based on neural networks can classify a document and define information zones based on a trained network. This eliminates the creation and maintenance of a template library by the user, but requires network training. Or providing a trained network to the vendor product.

I identified two zones: the new technology and the classical (saturated). When a technology is first introduced, it is very important to keep track of user requirements, since this is a new way of working. On the other hand, if the technology already exists for a long time, then you need to spend less time on requests for new research and development.

Technology maturity is a parameter for assigning time to tasks. But more weight has a product life cycle.

The product life cycle graph shows exactly where the product is located. Whether it is a startup or a giant with a long history.

I think that you are familiar with this picture and know that each stage is characterized by its own type of users.

  1. Initial introduction - Innovators
  2. Growth (growth) - the first users (early adopters)
  3. Maturity (mature) - earlier most (Early Majority)
  4. Decline (decline) - later majority (Late Majority), late (Laggards)

To move from the first users to the stream of clients, you need to skip the “failure” ( Geoffrey A. Moore “Crossing the Chasm” ).

I identified two zones: the “failure” and the zone of extinction. When you go "failure" to take into account the opinion of the first users is extremely important. This means that you need to implement requests first. On the other hand, if the product is mature, then greater priority should be given to innovative developments, rather than the implementation of customer requests. The paradox is that with a mature product you have the largest customer base and a huge list of requests. Nevertheless, I highly recommend in this situation to pay more attention to research, to be always at the top.

New Product
Mature product
New technology
Focus on user requests
Equally, but with a bias in R & D
Classic technology (saturated market)
Equally, but with a bias in R & D
Focus on innovation only

Also popular now: