Activity based planning

I’m reading Microsoft Secrets, an old book about Microsoft before 1995. It’s still a very interesting book as it looks back at some of the Microsoft practices for product development. One problem Microsoft had back then was how to select the features that should go into a product. Developers wanted some features that they liked and generally, whoever shouted the loudest got their features in. It was pretty much developer driven and a lot of it was copied from other products (yeap, Microsoft weren’t much of innovators).

The system wasn’t very good, so they finally discovered a better one, called activity based planning. This method started with the user in mind and asked questions like: how is the user using the software, what is the problem that the user is trying to solve. For instance … creating a budgeting system in Excel. This would be a big activity, which then can be broken down into smaller activities.

Once an activity is identified, it is mapped to technical features. These technical features can support multiple activities. For instance, loading images from the disk, or sharing components via OLE. These are technical features that ultimately can support multiple activities.
Activity to feature mapping is therefore a many-to-many mapping.
In the end, the features that supported more activities made it into the product whereas the ones that couldn’t be mapped to an activity were generally scrapped. It was a good principle to use when rejecting features as they usually had more features than they could implement.

This change in perspective helped in many ways. First the product became more aligned to what the customers really wanted, which is always the killer feature of a product. Second, the product management became a more important contributor to product development by giving a sense of direction to the product and saying … this activity is really important focus on that, or this activity is not that important. Product management could now simply interview the people and get feedback specifically targeted at the activities that users were conducting with the software.
But there were improvements that came “for free”. And one was that people wrote more generic code. The rationale was … I can change this feature I’m doing to support an additional activity with only minimal changes to the code. Supporting more activities was in fact a ticket into the product.

These are lessons that every company should learn from history and from Microsoft.


Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: