Posts tagged project management

Internal systems

Aug 30th

Posted by John Peltier in Product Management

No comments

One of the takeaways I’m finding in Bill Jensen’s book Simplicity is a reaction to the effect that information overload has on company productivity.  As there is more and more information to process to do one’s job, it becomes ever more important for a company to provide tools that not only provide access to information, but which help interpret the information in the sense of analytics.  So how does this manifest for a large company aiming to produce streamlined products for the marketplace, that will address (and solve well) a specific problem?

As a product manager with a multinational corporation, I find that (at least at my company in my specific division/subsidiary) there’s a contrast between the streamlined solutions we’re being asked to produce, and the cumbersome internal systems we use to collect and analyze the information we use to design such products.  The systems we’re building are “push,” but the systems we use internally are “pull.”   Some of this may be due to our company’s implementation of off-the-shelf requirements management and project management tools, but the net result is that the company does not make it easier to easily understand the decisions we need to make, much less make them.

I suspect we are not nearly the only ones.

One of the products I’m developing now is a service which can run client-server or on the web, in order to maximize the base of customers to whom we can provide a solution.  I’m finding that questions about–and design of–the internal management components to be used by company support representatives are getting short-changed due to the pressure to meet release targets.  This is certainly not unique to this one product, and the support angle hasn’t been ignored, but at the same time the support team’s “use cases” have not been considered with nearly as much diligence and interaction design as the product itself.   So in one sense, the sub-optimal experience product managers have with requirements tools is being propagated to the experience support reps will have with service management.

Something I need to reiterate within my organization.

, , , , ,

Interesting post about forgetting feature requests

Feb 27th

Posted by John Peltier in Marketing

4 comments

I ran across a blog post today suggesting that the work of tracking and logging feature requests is unnecessary.  As the thought goes, the ideas that keep coming up are the ones worth considering anyway, so those repeated mentions serve to remind the product manager of the market’s needs.

I find this interesting in its minimalism, but within a large software organization it seems like this might be difficult.  The product manager is often several levels removed from support calls, which is where a high volume of customer contact is made.  The product manager’s site visits, interviews and observations may be only a small percentage of the company’s contact with its customers.  So is it wise to trust that the product manager’s selection of contacts is wide enough that those same important ideas will bubble up to the top?

The degree to which a product manager spends time listening to the market also plays a part.  If the product manager carries products all the way through commercialization, time in market may be sporadic or limited; in which case, this concept would seem to be more risky of not hearing the “right” messages from the market.

Still, interesting food for thought.

, ,

Product Management vs. Project Management

Oct 26th

Posted by John Peltier in Requirements

4 comments

A frequent topic of confusion among software development organizations is the proper role of a project manager as compared with that of a product manager.  Let’s start by defining the terms:

A product manager is responsible for the marketing strategy, direction and features of a product throughout its lifespan.  A project manager is responsible for the success and progress of a project on behalf of the project sponsor.  The confusion in part can be alleviated by confirming that project != product. A product by definition lives beyond individual versions; whereas in most organizations, a specific version of a product is a project.  This is articulated in more detail at How To Be a Good Product Manager:

Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move move to a new project, which may be related to a different product.

Product managers are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined.

As a product moves through its life cycle, changes are often conceived and added to the project roadmap.  The product manager, interested in delivering the very best product to the consumer, is an advocate of adding features that will make the product better or fix oversights regardless of the schedule.  The project manager, on the other hand, is interested in specifying an agreed-upon set of requirements and working towards their completion within budget and on schedule.  These interests are inherently in conflict.

The answer?  In my view, the project manager should be provided a list of stories or requirements for a release (or scrum) that are prioritized by the product manager, so that the project manager has the authority and the knowledge to add and remove stories/requirements as needed in order to come in close to deadline and budget–after all, everything will NOT go as planned, and not all of them will be done on time.  What isn’t handled in release 1 is simply held over or deferred for release 2.

In theory, over the course of several releases, as the product is able to meet more and more of the original set of requirements, that product has the chance to succeed in the marketplace.

, , ,