Diminishing Returns

I read "Product Management is Politics" with some interest. James's post covers several areas that are perpetual (frustrating) truisms of product development, including the time-quality-features-people (pick two) dilemma. It got me to thinking about my own experience and perceptions.

The natural behavior of development teams is to make incremental improvements to existing software. Yes, there are some teams that go off in new areas or we'd never have new products or radically new features (and Popfly is an example of doing just that, so I'm talking out of both sides of my mouth). But my experience with most teams that are working on existing products is that they organize and plan first and foremost to fix known issues and implement the features that they missed the last time around. This is normal human inertial behavior: If you're on a path, you don't tend to leave the path unless a) something monumental stops them or b) something dramatically and obviously better comes along. (Or both a and b.)

More importantly, the development process is designed around inertia. You really don't want your development teams fluttering like butterflies from neat idea to neat idea for years. You want them focused on a well-defined problem so they can execute the heck out of it and either get more customers or improve the satisfaction of your existing customers. To do this, development organizations work from well-structured schedules; even with agile methodologies and monthly iterations, changing course can (and should) take a while.

But inertia isn't enough. At some point you reach diminishing returns. At some point customers aren't going to be that much more satisfied by fixing the next ten bugs on your list and they aren't going to flock to upgrade when you implement the next three features on your top features list. Worse, those incremental bugs and features become increasingly expensive to implement.

Enter product management. Part of the job of product management is to have a sense when the development team has reached diminishing returns and to raise its hand in a timely fashion and say, "You need to look over here for your next breakthrough in adoption or satisfaction." To be effective in raising your hand, you need to be aware of the part of the ship cycle your team is in: development teams are more receptive to ideas during the very early phases of a cycle and the very late phases. You also need to understand how the development team works. How do they process new ideas: do you need to create a demo, pull together some revenue numbers, or show them 35 customer interviews? Who are the people on the team who sway opinion and what does it take to get their ear? When, concretely, do they need to execute -- is the window large or small? Basically, you need to understand both the reason to do something at a pretty deep level (beyond, "Boy that would be cool") and you need to be willing to explain again and again without losing patience why they should so something. I'd also offer that you want to stay out of the business of telling them how to do it -- depending on how your development team works, sometimes telling them how to implement something yields more negative than positive energy.

But in between the key milestones, the best thing you can do is often to help them keep focused: keep quiet when you don't know for sure that the thing you're proposing will be notably better than the thing the development team is already doing. Talk with a couple of people whom you trust to help you frame the idea, but don't derail a dozen developers at a team meeting.

As a side note, the worst thing a product manager can do is to tell the team that they're building the wrong product some time between beta 1 and beta 2. Yes, some VP can swoop in and make such a proclamation. But speaking as someone who's had the "you're building the wrong product" fight several times (both giving and receiving), you have to realize that your development team is emotionally attached to their creation and you win few friends telling them that their child is ugly. Even if you're right.

Technorati Tags: Development process, product marketing

Comments

• Anonymous
  October 09, 2007
  Nice post John, keep them coming.