
Each requirement has a web of relationships with customers, stakeholders, market elements, risks, and competitors
In my last post I talked about the fact that agile methodologies are all about “doing the most important thing first.” This post is about figuring which is the “most important thing.”
As a product manager or product planner, how do you reconcile the following:
- Too many ideas
- Too many customers clamoring for their pet enhancements
- Engineering teams who have lots of “cool” things they want to implement
- The sales force screaming about the “must haves” of today’s “deal of the day”
Prioritization is a problem whether you’re doing waterfall or agile, and whether it’s a new product or an existing product. In the agile context, you have to determine your most important story, then execute on that story. Then on the next most important story, and so on.
This is easy to say, isn’t it – just do the most important thing first! But there’s a slight problem – how do you know what’s most important? If you’re a product manager or product planner, you have many constituencies, each with their own set of priorities, and each with more than you can possibly accomplish. You have to consider: customer needs and their desires (often as important as needs); company goals and strategies; your technical capability to execute on the story; tactical sales force needs; and let’s face it, personal assessment of the importance by everyone from the product manager to the engineer to the CEO herself.
And if you don’t come up with a prioritization someone else will – maybe an engineering manager, maybe the VP of Sales. And they’re not in a position to necessarily make the best decision for the company as a whole.
Now once you do make a decision, as the product professional, how do you justify it when those with axes to grind seek you out, or call you on the carpet in the executive board room?
For all these reasons, you’d better have a system – and it’s best if that system is visible, takes into account the interests of all the stakeholders, and in general helps you find the “right answer.” It’s even better if the system is not just qualitative, but quantitative, and traceable. This sounds a little like a spreadsheet, but as lots of product managers have discovered, spreadsheets have a host of problems:
- It’s hard to represent all the relationships you want to capture – to customers, market themes and other strategic elements, risks, competitors, etc.
- They aren’t very transparent
- They are terrible for acting as an enterprise knowledge base (if even stored in a sharepoint or wiki), and
- Who wants to, or has time to, create a big spreadsheet model?
So, you want something that’s a little like a spreadsheet, but is also
- Transparent
- Enterprise
- Purpose-built to handle the desired relationships to customers, market segments, competitors, risks, and marketing themes.
- Provides out of the box analysis
Well, I have one of these, and as a PM who didn’t have one in my last job, I must say it’s changed my life.