Things We're Thinking About

A Few Observations on Project vs. Product Management

For pretty much my entire career, I’ve been a project manager.  When Crowell made the jump into product development, I had an unexpected crash course in product management.  I had a strong background in managing service-based projects, so it was a short leap into product management, but a leap nonetheless.

Most of the usual project management issues also apply in the product management world, for instance: scope, resources and timelines.  These are all relevant in the product management world, but the “client”, in this case, is internal; there have been no external, paying clients to answer to.  This presents its own unique set of issues to deal with.  As a services company, we have an ongoing set of projects (with external paying customers) to work on and deliver.  This has had a significant effect on the resources and timeline for developing our products.

Paying customers always take prescedence over an internal product development project.  So, as the product manager, it has been a different (and occasionally frustrating) experience for me to try and manage to a moving deadline.  Having come from the customer-facing project management world, I had a tough time not sticking to a schedule (and working toward specific deadlines).  But, since this was an internal project, it rarely became an issue.

Delivery has also been sightly different for me in the product management world.  With a services-based product, all of the code, documentation and other intellectual property belong to the client.  So there is usually no need to worry about hiding how something was designed and coded.  In fact, it’s usually quite the opposite; clients want and need to know how their software was developed.  After all, they own it.

In developing our own products, we had to have a different approach.  The code and documentation we are delivering to our clients is, and is to remain, our intellectual property.  We have had to add an additional layer of development on top of product coding in order to protect our IP.  This, in turn, has added scope and time onto the development effort that I had to take into account.

I have had lots of mentoring help in making this switch from friends and former co-workers, so it has been a fun experience that I look forward to continuing.  One book that has helped me out is: The Four Steps to the Epiphany, Successful Strategies for Products that Win by Steven Gary Blank.  The book certainly gave me lots to think about and helped guide me through the process from an inside view.

–Kate McDonald