Feature Prioritization | Let’s Talk Product Management

I tend to view #ProductManagement as the intersection of UX | Technology | Business. There are many different rounds and levels of discussion that should occur before development begins. Without that communication, the development team will be led in a feature prioritization direction that is likely wrong for the user and therefore business. Marty Cagan, the author of Inspired: How to Create Products Customers Love defines the goal of a product manager the following way:

“To discover a product that is valuable, usable, and feasible.”

A product manager has to be knowledgeable in three spheres — in no particular order: (1) The Business’ Goals; (2) Viable Technologies; (3) User Experience. Building a process for debate and for evaluating new features or changes to existing products is key. I’ve found that creating a workflow showcasing the role of each stakeholder is a very powerful tool in that regard. It is helpful to break down the overall concept into the following components and consider each piece individually:

1. Roles & Responsibilities
2. OKRs and Development Resource Assumptions;
3. Quarterly Request Process Workflow;
4. Communication Plan and Requirement Submission Document;
5. Requirement Evaluation and Prioritization Principles;

The most important of which and begging the question:

How would you build a Quarterly Review Process?

First we need to start with assumptions about the team, business structure, and business goals. Then we can create a flowchart defining each stakeholder in a dedicated a swim lane. Whichever role is closest to the ground — the team member with insights into customer pain points — ought to be the starting point. This is where the Business Requirement Documents (or BRD) are written. In an established organization this would likely be a dedicated regional or market owner.

Prior to a Quarterly Review Meeting — ideally a month before development activities are to begin — the PM reviews each BRD with the business owners and schedules meetings with Engineering Leads. The point of this meeting is to discuss viability and the resources needed to complete everything in the upcoming development cycle.

Note: If there are Product Specialists in the mix, they would take over the initial review of the BRDs.

Following engineering’s buy-in, the PM then begins scoring feature requests. This is done with the business owners so that feature prioritization is as accurate as possible. Finally, the PM has everything needed to begin creating the first version of the Feature / Product Roadmap.

Note: The Product Roadmap is not to be set in stone. Further testing and communication during development should help guide each feature in a direction that aligns the business with customer.

How important is a Communication Plan in Feature Prioritization?

Beyond the obvious, that communication = good, a defined communication plan is essential for stakeholder management. It is fundamental in coordinating all stakeholders with the ever changing roadmap. It keeps business owners informed on product details and what their feature requests are shaping up to be. If there are missteps during development and / or engineering is building something that does not align with the customer and business, there needs to be ample opportunities to shift course and re-align. Assuming that the business units are able to accurately and consistently communicate their needs is a recipe for disaster. Also assuming that the product team expertly understands every want or need is just as dangerous.

During build-out, feasibility concessions are often pitched by engineering to accommodate ever tightening development schedules. To make good decisions, the PM must have their fingers simultaneously on the pulse of the customer and business. This means keeping business units in the loop and enabling them as an avenue for feedback early and often.

Therefore, the PM ought to prepare for weekly or biweekly reporting on the current status of development. Schedule biweekly and monthly meetings to field deeper questions with business owners. In addition to all of these reports and meetings, the PM needs to hold daily standup meetings with rank-and-file team members to quickly discuss barriers, wins, and tasks.

What are some good Feature Prioritization Principles?

Different businesses have different goals, but in the end it’s up to the PM to put all the pieces of the puzzle together. The PM should be able to quickly — and efficiently — identify the Minimum Viable Product for any feature or release. Center it around the customer / user experience with insights gained from written User Story Maps. These stories should be collaborative and discussed in a group and should be accessible to business units.

Following engineering’s resource assessment, the PM should hold a meeting with business stakeholders to score each feature or change. I like the RICE (Reach, Impact, Confidence, and Effort) method. Using it in a collaborative effort with the business team ensures that scoring is as accurate as possible and assures input from the business. Reach, Impact, and Confidence should all be based off information they have researched from their customers and users. Bias towards one’s own feelings and ideas is inevitable, so this is where the PM uses their soft skills to determine which feature requests to prioritize with the business unit.

In closing

I hope this was helpful! Open communication and establishing an iterative workflow process are the two main points here when trying to establish effective feature prioritization. If you have any other insights you’d care to share, please let me know! I’m excited to hear your thoughts.