Five Quick Questions to Ask Before Deciding to Build Features
Prioritizing features has always been a challenge to me during my journey into product management. One can waste tremendous human and financial resources, if either one of these scenarios happen:
- Building a feature customers don’t want and not building a feature that matters.
- Focusing on a feature that needs more resources than what is available at a time.
- Building a feature without realizing a better alternative already exists.
There’s no strict framework for product managers to follow, of course. I have seen product managers using different prioritizing schemes in their roadmaps. Some base their estimation on competitors, while others choose to focus on available resources of the company. The tricky part is that product managers receive user complaints, feedback or suggestions on a regular basis, if not too often. They are requested to make changes here and there, add more of this and less of that. So how can product managers quickly decide if a solution is worth pursuing?
My first task during onboarding week with Shopee, an e-commerce giant in Southeast Asia, was to research and recommend features to be built. As part of the User & Account team, I was in charge of improving and building SOUP — an access control system for the companies that basically (and hopefully) makes it easier for cross-regional teams to manage, control and integrate their accounts into a shared service.
After some research, I told my manager about a feature that will automatically grant access to contractor employees for an effective period of time based on their contract. The managers, therefore, won’t have to go back to the system and manually remove access permission one by one, after the employees leave the firm. Would this feature be needed, and should we prioritize it in our next release?
My manager asked me five questions in 10 minutes that helped me find the answer myself. I found these questions extremely helpful, if one needs to make the decision on the spot about which feature is of utmost priority and which one can wait:
1. How severe is the problem this feature is solving?
Severe, as in how many people are being affected, and what is its urgency estimation? In short, why are we solving this problem?
In my case, I estimate the company might have at least 1,000 part-time employees or interns across the region per month, all of whom have varying contract durations. Since access permission is approved by their managers, it is also their responsibility to remove access for people no longer on the team. This feature will, therefore, save a huge amount of time and effort, as they don’t have to go back to the system and manually tick off the box every time a part-time employee off-boards.
2. What will be displaying on the front end?
- Name of the employee
- Types of access permission
- Contract duration, including start date and end date
- Options for managers to automatically revoke their access
3. What is the logic behind the back end?
If the current date passes the employee’s end date, then the access is automatically revoked.
4. Are there any alternatives out there yet?
It’s in this step that I figure out we already have an alternative out there, so much more simple and obvious, that I was surprised at why it didn’t cross my mind at all at the beginning.
5. Do we have enough resources to proceed at the time?
This question uses the input broken down from points 2 and 3. I didn’t come to this step at the time, but this is definitely a very important thing to bear in mind, because sometimes, constraints in resources are the culprit for a delay in product delivery. You definitely want to direct resources into what is of utmost priority first.
Product managers have to maintain incredible patience and clarity in order to absorb a massive flow of user feedback and suggestions from other stakeholders. It’s always good to develop a quick “framework” that helps break down the features quickly to determine their priority level in the queue.
