You can always count product manager’s strategy skills like innovative thinking, blue ocean approach and others. But on daily basis we use more practical tools and approaches. This article is about working with feature requests and product requirements.

The main axiom of managing requests is that feature requests from customers, partners and internal teams are not requirements to the product. This is because every request can be split into several requirements or, otherwise, several requests can be combined to a single requirement.

Let’s use an example – a calculator app. You’ve received a request to add binary numerical system to the app. This particular single feature raises following topics, each of them can be converted to requirement.

Supporting arithmetic operations.
Supporting conversion from/to. This will impact the functionality of decimal system. For instance, you need to support conversion from decimal.
Supporting logical operations.

You see that no one asks for logical operations for binary if you have no support of such system. The feature request is about a particular numerical system, but it has several requirements underlying.

Probably this is so obvious. There are a couple of pitfalls hidden. First of them is managing feature requests and product requirements in a tracker.

Definitely having a single system for tracking and planning is better than having two. At least you need only one tab or application window opened. Please consider using separate types of records for managing requests and requirement rather than a single one. An example from my experience. I’m receiving from two to four new feature requests every workday, submitted by support team. You can easily imagine a number of items logged. Product’s project list looks like an extremely long list. Having “requirement” record type and “feature request” makes easier review and planning. If several requests are an origin of a single requirement, I make a reference link. And after reviewing I can close feature request with labels “planned” or “rejected”

The second pitfall can be in requests gathering. One way is getting them via support channel. This is a nice way, when you receive filtered and cleaned up items. On another hand this is not a visible process to your customers.

Therefore, vendors, especially for cloud software, may use portals for getting feedback.

^{Zendesk feedback portal}

This method adds visibility, separates requests from requirements. Now your work is doubled, though. You need review and comment them fast – customers don’t like silence and you’re communicating publicly.

And the worst thing is tracking and marking items in the list as planned, not planned, completed. Remember that feature requests are not requirements you have to keep in mind dependencies. Going back to a case of supporting binary in calculator app. How you should track this request in public portal if you implement only arithmetic and conversion without logical operations.

Every product manager chooses own solution there is no universal approach. However, we should always remember that a lot of important details may be hidden in a simple topic.

Feature requests and Product requirements