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 important for a Reactor to get out of this mode. First and foremost, it requires determining what projects and tasks are most important to the business, and focusing on these. This sometimes means taking a difficult stand regarding less important roles and tasks - some of which may be considered urgent by their owners. It may be necessary to say "no" to a Sales request, and then make sure that both the requestor and the PM's manager understand why, as well as when the request might be addressed.

Unfortunately, it is common for PMs to be given responsibility for multiple products or very large/complex teams. The multi-product PM becomes the hub for several wheels - maybe even all the wheels - and must find ways to keep things rolling. The more balls that a PM has to juggle, the harder it is to make good decisions about each one. This may mean reducing the number of products each PM is responsible for, or prioritizing them.

Only by focusing and getting out of reactive mode can the overwhelmed PM succeed.

A Coordinator is a conduit for passing information, opinions and decisions from one part of the team to another. Typically a Coordinator PM has (or exerts) little authority, and often works within an Engineering or Marketing organization. This PM can play a valuable role of propagating a vision that's developed by management, by ensuring that Marketing and Engineering are in synch regarding product plans and expectations, and most importantly, by gathering and communicating customer requirements. The Coordinator role is most effective when the PM is able to effectively interpret between the players, explaining Engineering's schedules to executives and clarifying/ prioritizing customer requirements. It's also appropriate when an executive is a visionary and/or market expert, which is common in many start-ups.

The most effective Coordinator PMs act as a facilitator between teams, actively resolving conflicts and solving problems. In this role, the PM serves as a hub that constantly monitors the spokes of the wheel, making adjustments as needed. This is where the real potential for great product management begins: The PM is the only person who is truly in a position to see what is going on in every area that affects the product, and is thus the best person to identify and solve problems.

An Initiator goes one step further: this PM is a leader. An Initiator understands the business strategy, the customer requirements, the marketing strategy, and the capabilities of the development team, and synthesizes tactics that take advantage of this broad knowledge. An Initiator PM sees a customer problem, knows that there is no adequate solution in the market, sees how a product concept might fit into the company's business strategy, and recognizes that the development team has the ability to solve the customer problem in an effective way. In this fashion, the Initiator becomes the source of the product vision, and the one who drives it to successful completion. But an Initiator plays this role in many smaller ways that are nevertheless significant. In every team meeting or executive briefing, an Initiator is looking for ways to advance the cause in leaps, rather than in small steps. This PM is the one who sees all the sides to a problem and cobbles together an approach that would not be obvious to someone with the narrow view of, say engineering or marketing. Needless to say, this is the PM who is most likely to be responsible for breakthrough products.

There's a sub-type of Initiator PMs that bears mentioning. Some product managers are sufficiently adept at product planning or product design that they are Inventors. As the source for innovative ideas, they can bring a product from concept to completion by designing it and working with the team to develop the concept into reality. 

There are pitfalls to being an Inventor PM. Getting too involved in the details of development can get in the way of the never-ending task of understanding and interpreting the customer's needs. Sometimes Inventor PMs take inordinate pride of ownership, leading to turf wars with development. Nevertheless, a PM who can make significant contributions to the product concept and design can be a valuable commodity.

These different product manager roles are not just a matter of the PM's personality. They also result from an organization's structure and expectations. Each company has a different idea of what the hub of the wheel looks like - some expect a low impact Reactor, while others demand an Initiator. It's important to find the right fit between individuals' capabilities and company expectations. But it's also important for companies to give a good, hard look at what kind of hub they really want on their wheels, and ask whether they are giving their product managers the opportunity to make the wheel as efficient and effective as possible.

Comments

Post a Comment

Popular posts from this blog

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...
Read more

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 - ...
Read more

Consistency vs. Innovation

One of the most vexing user experience questions is: When must applications be consistent with each other? When is it OK to invent news ways of doing things that require users to relearn established methods? There is rarely an easy answer, but a Product Manager can play an important role in making these decisions. Most of us assume that it's a good thing when a mouse click performs the same action in different applications. Few of us miss the bad old days when every word processor had its own conventions, and there were no Windows interface guidelines and web interaction conventions. De facto standards have been created by successful products and suites, such as Microsoft Office and the Adobe suites. If you've learned one application, you've learned most of what you need to know to use another. But product designers are constantly confronted with opportunities to do things in a better , but different way. Is consistency an inviolable "must", or, as the saying ...
Read more