Wednesday, April 20, 2005

Products Versus Projects

Last night, I attended a wonderful discussion on the future of computing at a local (Austin) Chapter of IEEE. The main point I pulled out of this is that knowledge (versus "manpower") has become the most valuable asset going into the 21st century and is something that needs to be nurtured or lost. To quote the Speaker, Steve Teleki, "Knowledge workers are currently considered costs when they should be considered capital assets." The speaker went on to suggest that it is in the best interest of all knowledge workers to assume responsibility for staying technically viable and manage their productivity and careers.

As a Product Manager, I was thinking about the implications that our economy and tactical business focus is having on our longer term prospects for success. The business climate of the last few years has created an environment where many technology businesses are run like a series of discrete projects: where teams of engineers, for example, are hired or contracted, then "released" along with the product. There is great emphasis on project management skills these days and I would argue that project management is not the best approach for product or business management. It's all about the event (product launch) and not about growing skills, businesses, and relationships.

Every sales person can vouch for the wisdom that it is a lot easier to keep a customer than it is to acquire a new one. When we plan one release at a time, we limit the ability of the people who sell our products to build the trust and relationship necessary to expand their sales. Our customers mirror the same commitment we provide to them; can you blame them?

When we plan one release at a time, we fail to advance our product capabilities and core competencies through making optimal use of the experience gained from the prior release. Often we do not put in place the measures to improve because without a follow-on, we have no justification for the effort. In the most dysfunctional organizations, poor quality and schedule overruns are introduced because the people creating the product know they will not be the ones who will have to maintain it.

From a business perspective, we know there are many reasons to not take a longer term view and commit beyond the current release, but I believe the potential rewards for doing so are great.

I want to invite those of you who read this to share your thoughts on this topic.

3 comments:

Brian Massey said...

The company I work for uses an "agile" process to deliver its work. Part of this process includes a constant series of rapid releases--as often as every week. This keeps the customer constantly involved in the development process.

I think that this is what our customers are asking for... from the development of technology products right down to how we market to them.

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...
This comment has been removed by a blog administrator.