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:


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:

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

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:


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)

breakdown for new products

For more mature products

 

breakdown for 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:

Back to Part 2   ::   Back to Part 1