The Hub

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

Just Saying "No"

"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 Thinking

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

Which Customer?

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

What Business Are You In?

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

The Vision Thing

A US president once said he wasn't very good at "the vision thing." (He wasn't re-elected.) Product managers can't afford to be anything less than great at the vision thing. The product vision is the glue that holds a team together. It's a great tool for herding all the development, marketing and executive cats in the same direction. But it needs to be sound, it must be straightforward and compelling, and it needs to be communicated well and often. A product vision is pretty much what it sounds like: something that enables anyone to see clearly what the product is, does, and who it's for. Beyond that, there isn't really a formula for defining a product vision - it's the product of good research, clear analysis and, most importantly, imagination. A good product vision usually seems obvious in retrospect:. Take the iPod: An elegant-looking pocket music player that non-techies could learn quickly and easily download songs from an online stor

Focus Groups, and Unfocused Groups

Sometimes useful revelations come from focus groups. If you ask the right group of people really good questions, you can validate (or disprove) a theory. Sometimes you can identify customer problems that provide opportunities for new product solutions. Sometimes . The trick is going in with the right expectations, and knowing when alternative methods, such as customer interviews and surveys, may be better. I've used focus groups to explore customer attitudes, and to validate the viability of product concepts. Careful questioning about "how you do it now" can be useful, especially when the group becomes engaged and discusses their personal experiences. This is where focus groups can work: getting people to open up, describe their experiences and compare notes about current problems. (Important note: Having a top-notch moderator is essential: if you can't shut down a loudmouth, your group will be a waste of time. But it can be hard finding a good moderator who unders