Measuring success through innovation

Product roadmaps can often become innovation roadblocks. If the roadmap gets translated into a timeline, then the team is forced into an the awkward position of having expectations against which they can only fail.

Photo: Baron von Flickrhoffen

The time required to meet most project deadlines is usually underestimated. There are ways to fight that like padding estimates and shifting resources, but deadlines are meant to be missed. And there are always new challenges and opportunities that popup midstream that you’ll never be able to predict.

As a result, the team gets rewarded for cutting out work and reducing the scope of a project in order to meet the goal. Hold on. That doesn’t make any sense. People get rewarded for delivering less?

In a discussion about Yahoo!’s tendency to focus on time-driven roadmaps with some colleagues yesterday, one person suggested that Product Managers should be rewarded for the number and quality of the features that make it into production. The roadmap then becomes more like a strategy or possibly just an approach to driving toward a vision.

I really like the idea that innovation is the goal rather than beating the clock. I can imagine the lively discussions happening up and down the management hierarchy, too. How much more interesting would it be watching a weekly report that showed all the cool stuff in development rather than a big timetable of all the projects that are running late?

No doubt it would be a lot more fun to congratulate your staff for the bright ideas that they’ve come up with and delivered rather than for the all-nighter they pulled to push out the same old s*#!t.

2 thoughts on “Measuring success through innovation”

  1. *groan*

    No, actually, product managers shouldn’t be graded on adding features.

    The problem with that sort of approach is that you’ve got feature laden applications and services that never really get the sort of development they should. As a real, live fer’instance, yesterday I was talking with one producer about how he could add a new feature to the platform. I asked him what his goal was. He told me. I then pointed out that his platform JUST LAUNCHED a feature that did exactly what he wanted to do, required less maintainence, and if promoted and tweaked properly, could revolutionize the industry.

    What producers should be measured by is the level of impact their efforts made on the product. Innovation is one aspect, product improvement and reliability another, increased traffic and “stickiness” a third.

    People don’t really need a WiFi-enabled, 3.2 megapixel toaster. They want a tasty bagel in the morning.

  2. Why not let the customers and the market decide?

    This reminds me of the challenge of putting measures on developers — does lines of code equal good code? Not very often. Pay-for-feature has same issue (bloat as JR points) and I can imagine the debate now over what ‘is’ a feature.

    Shouldn’t the value of the features selected and resultant roadmap be traced back to the overall success of the company (revenues, share, customer loyalty) or, if granularity is needed, also have the customers who requested and rate the feature implementation relative to their needs.

Comments are closed.