Product Management Journal

The role of the Product Manager is unique in the business world, particularly in technology companies. No one else is responsible for working with so many different disciplines - Engineering, Marketing, Sales, Support, executives, and others - on a daily basis. The role is really the hub of the product organization, and the strength of the hub is the key to how well a wheel rolls. I've seen Product Managers perform in very different ways, with different results for the organization. Some of these include Reactors, Coordinators, and Initiators . A  Reactor  is a PM who waits for balls to be thrown his way, juggles them as they arrive, and returns them or passes them along as quickly as possible. A reactive PM is often overwhelmed by demands from different directions, and is rarely able to inspire new strategies or lead new initiatives. PMs tend to fall into a reactive role through a combination of overwhelming external demands and difficulty prioritizing them.  It's importan

"No" can be the toughest word to say. Nobody likes to hear it. Executives generally hate to be told "no." But sometimes it's the most valuable word in a product manager's vocabulary, especially when it makes "yes!" possible. You can't build all your ideas, so someone has to say no to some of them. That means saying yes to the right ones. Any good product development organization has more good ideas than it can possibly execute. Sometimes the ideas come from executives, sometimes from engineers, sometimes from customers and sometimes from product managers. It's the product manager's job to understand the company's business, the market situation, the customers, and potential customers well enough to make a case for what gets a yes or no (or a "later"). Each case will involve many factors - business goals, investment issues,  sales considerations, competitive conditions, technology opportunities and development resources -

Agile development processes have had a pretty big impact on product management. An agile product manager has to be adept at bringing clear customer requirements into an iterative development context. This can be a terrific opportunity for product management and engineering to innovate during the development process. But I've found that this kind of agile approach can be applied to a more traditional development process, too. In an agile world, a product manager (often serving as product owner, as well) is responsible for delivering customer requirements in the form of use cases as the team goes through a series of rapid development cycles. The product design may change after (or even during) each of the sprints, so the PM is responsible for restating the customer requirements in the new context, as well as creating new use case examples. All the while, the PM must keep the product vision and goals at the forefront. In a traditional "waterfall" development process, the

Everyone agrees that it's good to listen to  what your customer wants. But which customer should you be listening to? This can be a surprisingly difficult question to answer, and getting it wrong can have unfortunate consequences. Most companies have many types of customers. They can be sorted according to purchasing power, loyalty, enthusiasm, early/late adopter, knowledge, purchase frequency, and many other characteristics. You can also add in potential customers, who are often the key to success, but you may not even know who they are yet. Some customers will let you know what they want. Some are articulate. Some are loud or persistent. Some are brutally honest, while others try to ingratiate themselves by telling you how great you are. Others, you will never, ever hear from. There are several traps that the most well-intentioned people can fall into. Here are some customers that we're always tempted to listen to, and then try to please: The squeaky wheel . This is

It's pretty hard to develop the right products when you're not sure what business you're in. Or what business you're not in. A few years ago I joined a small company and was asked to design a new delivery platform for their content and interactive applications. The platform, which would manage user profiles and transactions over time, needed to be a very sophisticated system that would underlie all the company's products. I diligently began investigating the user requirements and existing products that did similar things. As I gathered data, I realized what a large undertaking this would be. I talked to the development team and began to get an idea of the resources that would be required, and did some thumbnail calculations. Something was wrong. The company's strength was in developing interactive content - video and accompanying web-based activities. While a new back-end platform was clearly needed, this was not something that they had experience develop