Managing Requirements: Who's in Charge Here?
I spoke at length with a senior product manager at a $1 billion-plus software company last week and he asked me, How should I manage all of the incoming feature requests and prioritize my roadmap? And how can I best figure out where where we should be going? He was struggling with the fact that the product serves multiple market segments and there are two product teams trying to prioritize what comes next. So what did I say?
Efficient requirements management takes skill even in single product / single target market companies. But in more complex organizations it takes real expertise.
He was already off to a great start because he knew that the purpose of requirements management is to ensure that the team quickly validates and meets the needs of its customers. And it was clear that he had experience capturing customer feedback and crafting intelligent user stories and requirements.
The product management teams also had a reasonable relationship with engineering — so he was not talking about that major intersection point and common collision zone. They have reasonable agile development processes in place for backlog grooming and sprint planning. He was specifically focused on addressing how he and the broader product management team should better prioritize the roadmap to deliver customer delight.
So, I paused and here are the four tips I shared with him (based on being an early employee or founder of six software companies including Aha!) to make roadmap planning and requirements management more efficient, meaningful, and enjoyable.
Goal first As a great product manager you must establish a goal-first approach and a true north for your product based on the best information you have. Reaffirm your strategy and tweak it as necessary, but stay grounded in what you are trying to achieve. This is even more important if there are multiple teams involved in managing the product.
Product needs to agree on the strategic imperatives (or themes) first and then align the roadmap and requirements against them (and make the necessary trade offs as a group). Explain to the company and product team where you are headed, along with the value that new releases and features will deliver to customers and the business. If you do, your company and team will follow. If you lose your direction or drag the team back and forth the complaints will beat you down.
Who’s in charge here? In all organizations there are competing interests pulling product managers and demanding different enhancements and improvements be made to the product. That’s healthy and no one said product management was easy. There is a reason that PMs are considered the CEOs of their product. They need to make tough decisions and lead. This is one of the main problems that the PM I spoke with was grappling with. It was not clear who ultimately was in charge. Yet, someone needs to be the boss.
Even with great teams where consensus and trust comes easy, someone needs to make the final call when there are legitimate reasons for disagreement. If you do not resolve these disagreements and try to push the indecision down into engineering, they will either smile and start building what they think is right or thrash and simply stall out.
Write more (and less) down I was once wrote a 35-page marketing requirements document. It hurt. Worse, no one read it because it was just too long and too detailed. It was boring to read and that hurt more. However, too much documentation is unlikely a problem for you and your organization. Engineers typically complain that there is not enough written down, which makes it impossible to focus their efforts and build what matters.
So, I encourage you to capture features and their related stories or requirements as bit-sized chunks. Not only will you have a record of what customers and other key groups are requesting, but you will be able to incrementally improve the ideas and add additional details over time. The key is to capture what is essential and what the new capability should enable, but not detail every last bit of minutiae or explain how engineering should build each feature.
Rank features based on business value If you are doing the first three, this last one is relatively easy. If you are not, it is nearly impossible to quantify the value of each feature and do a good job of prioritizing what comes next. First, you need to know what the goals or key business drivers are for your product so you can create a scorecard that includes the key metrics. Second, if it is not clear who owns setting priority your scoring will not be trusted, so it’s critical to know who is in charge. And finally, if there is not enough detail per feature it will not be clear as to what functionality the feature will actually actually deliver. So, assuming you have the first three figured out, build your scorecard so you can quantify the value of features against the metrics that matter to your business. Then rank them based on those scores. You can do this type of value estimation in Excel or in a purpose-built product management tool like Aha!
I also suggest that you use a simple “effort scale” at this point, so you know how much each feature will cost in terms of resources. This is not the “official” effort estimate, but it will give you a sense of what it will take and you can take that into consideration for your roadmap planning.
Requirements management should be a continuous process throughout the lifecycle of a product and requirements should be generated by lots of folks including: customers, partners, sales, support, management, engineering, operations, and of course product management.
Yet, it is up to product management to determine the priorities and make sure they are aligned against the business goals. If you follow the four recommendations above, you will be well on your way.
