Feature Prioritization & Product Road Mapping (Part 3)
Product Management really starts on Release Day
The real challenge of Product Management starts on release day. From this day forward, the PM has the additional expectations: customers (existing & potential) and industry commentators and 'the market in general'.
This creates additional limitations on the PM process - a release schedule is tempered by:
- Bug fixes
- Customer Support - often second line support has to rely on the development to do 'inline' bug or data patching
- Operational research, development & tuning
- Design or UI improvements as a direct result of customer feedback, either from focus groups, beta testing or from the live service.
Once your product or service is live and available to customers, tension of 'new goodies' vs customer gripes and 'fix what's out there already' escalates, with different interests within the company taking predictable positions:
- Customer Support wants to see a perfect service.
- The Partner / Alliances Manager wants to see new capabilities (unless existing issues are crippling his existing accounts).
- Ops want a nice stable and predictable product - particularly if the product has just been launched and the product is expected to scale up and there are some known performance limitations in the future.
- Development wants to have fewer masters and stop being dragged into every single issue, as they appear to be at the beck and call / whipping boy for everyone.
- Marketing wants a nice stream of great stories: a blend of customer success stories and exciting new features.
Result: Product management is caught in the cross fire - and this politicking represents the hardest part of a Product Manager's role.
What goes into a release once your product is wild and live?
How do you balance these requirements? From my research and experience, I think there are several schools of thought:
- Mega prioritization
- Creation of Maintenance teams for released products
- Ring Fence development time into sectors
- x.0, x.1, x.2
- Appeasement
Mega Prioritization
Clearly the Feature-Value Matrix could be expanded to include every new feature request, every bug fix, every customer comment etc. As I mentioned in my assumptions, I haven't seen such a holistic mechanism ever work - particularly in small or even medium-sized software teams.
Creation of Maintenance teams for released products
Larger companies - and with particularly products with longer release cycles (ie years) and colossal implementation cycle times (think of ERP vendors) - often build secondary teams and have totally separate code bases for their more mature products.
I can't comment too much on the processes involved, as it has been years since I worked at this end of the software industry. There's a lot of duplication of work between these development and maintenance teams as issues (such as retro-fitting to mature releases and fixing critical bug fixes that are still apparent in upcoming releases) need to be applied in multiple code sets by separate teams with slightly different objectives and release cycles. Additionally, a lot of knowledge has to be duplicated across the organization due this multiple personality requirement.
Suffice to say that this doesn't work for start-ups. Perhaps this defines the boundary that a small software company crosses to consider itself mid-sized? Comments anyone?
Ring Fence development time into sectors
Loosely divide development time or the project plan in 3 separate areas:
- New Projects (as listed in the Feature Value Matrix)
- Bugs (as prioritized in the Bug Database)
- Usability Improvements / Customer Feedback (as determined by Customer Support / Beta Testing feedback, Release Management)
What's the breakdown?
For a product that has recently been released and with a near immediate implementation cycle, I continually see that not enough effort is spent on Usability Improvement and Customer Feedback. Below are my recommendations. Note that for mature products, then operational improvements (eg better reporting & scalability tuning) could be classed as either New Projects or Enhancements.
For recently launched products (your feedback comes your focus groups or beta trials) |
For more mature products
|
x.0, x.1, x.2
Larger software houses tend to only add major features in x.0. Subsequent releases concentrate on essential bug fixes. Smaller companies tend to have more rapid release cycles and can squeeze in more features in each release. So, x.0 is more of a marketing story than the addition of a major new feature. The principle is the same, but subtly different:
x.0
|
Major release
|
x.1, 2
|
The Hot Fix release which comes out quickly
after the x.0 release, as errors are rapidly discovered. Often
x.2 is a second hot fix release and represents the stable
platform release that you would actually ask your most prized
customer or your mother (for example!) to install.
|
x.3
|
This is the first release that concentrates on Usability. The product has been out in the hands of users and there is enough feedback to focus on making the product easier to use. The problem is that many software companies tend to 'go light' on usability improvements. It is important to continually dip into product focus groups, as the voice of the customer is SO important to hear. Just getting reports from your Release Manager or Customer Services Manager only gives you half the story. |
Appeasement
Simply allocating features to the next release based on who shouts the loudest. This is the fall back position! (For an amusing list of who to appease first, see this article How to Decide What Bugs to Fix When).
Final Thoughts
Endless prioritization between bugs, new features and usability improvements (aka Uber Prioritization) is crippling and frustrating to product management process. In discussion with my peers, we all agree that this is a thorny problem - and a blend of these solutions is most probably employed, creating a loose and fluid arrangement, requiring the support and buy-in from a variety of separate interests.
Product Road Maps & Money
Product roadmap indicates where your product is headed - hopefully towards revenue & profitability. A clearly articulated road-map with milestones and associated dates is an essential document for any fund-raising or valuation exercise.
Continuing missing these milestones by a wide margin as a result of poor project planning makes a mess of that all-important track record, making subsequent investment rounds harder & harder.
Long range road-mapping frequently under estimates release dates. My conclusion is that that, at the highest level, product managers ‘forget’ that released products require a LOT more time spent on usability AND operational & scalability issues become increasingly dominant. The days of lightning fast development and deployment are over!
Part 3 gave us:
- New products vs mature products.
- Road maps and money
Back to Part 2 :: Back to Part 1