Requests from users and product requirements
A lot of articles and books about the work of a product manager, consider issues of strategic thinking and innovation. Of course, this is the basis. I also like to pay attention to daily routine tasks. One of such work with user requests and product requirements.
The axiom is that requests for functionality from users are not product requirements. A request can be easily divided into several requirements, and vice versa, one requirement consists of several requests from users.
Let's look at a simple example - the Calculator application. You have received a request: add support for the binary number system. It can give rise to several product requirements.
As you can see, initially the user did not ask for support, for example, only logical operations. The query about the number system as a whole, but it contains several requirements.
Perhaps this is all obvious. But the process of working with queries, if it does not give importance, can add problems. The first pitfall - keeping records in the tracker.
Obviously, having a single system for user requests and product requirements is better than two. Well, at least you will only have one window open. It is important to have different types of objects for records. An example from my experience. I get somewhere on average from two to four user requests every business day. You can submit volume. The list in the product backlog is huge. Having two types of “requirement” and “feature request” entries allows you to customize filters, build backlog of a specific version, and make links between requirements and queries to track history. Moreover, after consideration of the request, it can be closed with the marks “planned for release” or “will not be implemented”.
The second aspect of the work is the collection of requirements directly. One way is to get them through technical support. This is a good process, as a result of which you receive a filtered query containing the essence. On the other hand, it is opaque to your users. Many may not see that such a request was, and re-apply.
Therefore, vendors, especially those making cloud solutions, can use portals to get feedback.
Zendesk feedback forum
This mode improves visibility. Separates requests from requirements, because the systems are different. But now your work has doubled. You need to quickly view new entries, comment, answer questions. Silence, especially in public communication, is unacceptable.
But the most difficult thing is that now you have to track and label requests in some way to mark those that are planned for implementation, or vice versa. Returning to the example with a calculator. As in the portal, you need to mark a request for support of the binary system, if you plan to implement only arithmetic operations and conversion, without logical operations.
Each product manager chooses their own solution. There is no universal approach. However, it must always be remembered that even such a small process as collecting and processing requests from users can contain many hidden topics, and it is easy to double the work.
The axiom is that requests for functionality from users are not product requirements. A request can be easily divided into several requirements, and vice versa, one requirement consists of several requests from users.
Let's look at a simple example - the Calculator application. You have received a request: add support for the binary number system. It can give rise to several product requirements.
- Support for arithmetic operations.
- Conversion support. This, incidentally, will affect the existing decimal system. It will be necessary, at least, to make buttons in the interface.
- Support for logical operations.
As you can see, initially the user did not ask for support, for example, only logical operations. The query about the number system as a whole, but it contains several requirements.
Perhaps this is all obvious. But the process of working with queries, if it does not give importance, can add problems. The first pitfall - keeping records in the tracker.
Obviously, having a single system for user requests and product requirements is better than two. Well, at least you will only have one window open. It is important to have different types of objects for records. An example from my experience. I get somewhere on average from two to four user requests every business day. You can submit volume. The list in the product backlog is huge. Having two types of “requirement” and “feature request” entries allows you to customize filters, build backlog of a specific version, and make links between requirements and queries to track history. Moreover, after consideration of the request, it can be closed with the marks “planned for release” or “will not be implemented”.
The second aspect of the work is the collection of requirements directly. One way is to get them through technical support. This is a good process, as a result of which you receive a filtered query containing the essence. On the other hand, it is opaque to your users. Many may not see that such a request was, and re-apply.
Therefore, vendors, especially those making cloud solutions, can use portals to get feedback.
Zendesk feedback forum
This mode improves visibility. Separates requests from requirements, because the systems are different. But now your work has doubled. You need to quickly view new entries, comment, answer questions. Silence, especially in public communication, is unacceptable.
But the most difficult thing is that now you have to track and label requests in some way to mark those that are planned for implementation, or vice versa. Returning to the example with a calculator. As in the portal, you need to mark a request for support of the binary system, if you plan to implement only arithmetic operations and conversion, without logical operations.
Each product manager chooses their own solution. There is no universal approach. However, it must always be remembered that even such a small process as collecting and processing requests from users can contain many hidden topics, and it is easy to double the work.