If you want to be a good product manager, save some features for later. It’s important to include enough functionality when a product is first released, though there are legitimate reasons to delay the addition of some non-essential features for future releases, including:

• Customers have difficulty processing too many features at once. With new products, it is too easy to get into “feature overload” and make it hard for users to focus on the most important functionality. Extra features may divert attention from the truly differentiating elements of the product, so much so that some customers may get distracted by the less important elements and lose sight of what truly adds value. However, adding new features over time allow users to slowly acclimate themselves to new functionality as it is added.
• Fewer features initially allows you to capture more value later. Some “one hit wonder” products release all of their best functionality on their first release, then fail to follow it up with subsequent improvements. In many cases, this problem could be partially resolved by staging their incremental releases. If all of the truly worthwhile features are in the initial release, it will be a challenge to capture additional value later through price increases or add-on modules. Instead, a slimmed-down Version 1 product with just the essential functionality may be enough to prove the value of the product and garner customer acceptance, paving the way for you to better construct a roadmap which will capture more value from existing customers and target new customer groups. This provides more flexibility for charging for add-on modules or overall price increases as the product is enhanced over time.
• Staging features provides you the ability to adjust new features based on market feedback. There is one certainty in product management — you always know more tomorrow than you did yesterday. What may seem like a great set of features before your initial release may turn out to not necessarily be the case after you launch. By holding some features back initially, you get the benefit of customer feedback. Once users interact with the product, they will be able to provide feedback not only on the features you have, but more importantly the features you do not have. Functionality you maybe previously thought was crucial may turn out to be less important, and innovative ideas which you had never thought of may be suggested by your customer base. Feedback based on real-world experience will allow you to identify new directions and adjust your future roadmap, saving you from potentially releasing less-worthwhile features and allowing you to put energy and effort into more valuable functionality.

As product managers plan enhancements and additional releases, an awareness of potential future features will help establish the foundation for the product roadmap. However, product management is a marathon, not a sprint, and product managers need to look after the long-term success of the product. Instead of trying to release any potentially relevant feature right away, product managers can release a good set of essential functionality first, allowing for quicker time to market. Then, by holding some features back and staging future product releases, product managers can better establish a compelling roadmap to stay ahead of development while also preparing for any changes ahead in the market.

Product managers need to have a much broader view, seeing and understanding everything from the underlying customer needs to the business model to the product roadmap to the go-to-market strategy. Unfortunately, it is all too easy for product managers to fall in to feature-focused development mode, especially for online products and those developed using Agile methods.

Why does this happen? A few possible reasons:

• It is perceived as a relatively “safe” approach to product management. Implementing changes which have been requested is a not very controversial approach, after all. If a myriad of requests come in (and they often do), someone needs to choose which ones get addressed first. Product managers can easily get overwhelmed with the impossible task of trying to come up with a prioritization approach which attempts to please everyone both internally and externally. Instead of focusing on value-adding strategic activities, they may end up spending a majority of their time trying to deal with these never-ending feature lists.
• The prevalence of online tools which allow product development teams to capture input from users — everything from dedicated tools like Salesforce Ideas to social media platforms like Facebook and Twitter — has also put increased emphasis on feature lists. A product manager no longer needs to plan a customer visit or pick up a phone to get input; just put a query out on one of these sites, or look through what customers are posting themselves, and it will likely generate a large list of potential incremental enhancements. Unfortunately, just counting the number of times a specific idea is mentioned — or letting customers themselves vote — does not a product manager make. These tools are useful if used appropriately and in conjunction with other ways of obtaining a customer understanding, though they are not themselves a substitute for a product manager.
• Inexperienced product managers without sufficient training and guidance do not know any better, and assume their job is just to collect features, prioritize them based on some criteria, and then make sure they get implemented. Many do not realize that there is much more to the role, and with pressure from others within the organization (e.g. “Make sure you keep the developers busy!”), their focus may extremely limited.

So, how does a product manager prevent this from happening, or break out of the trap if it already is? Do this by taking successive steps back from the feature prioritization exercise. Ask yourself (and your team members) these questions: What is the purpose of the feature? What problem does it solve and for whom? How prevalent is this problem? Are there other ways to solve this problem? How important is it that we solve that problem for that customer segment? What segment are we targeting and what are the most important problems to solve for them? How does this support the product strategy and roadmap?

It is easy to get sucked in to the feature prioritization spiral, though good product managers need to stay above the fray and focus on the broader and more important strategic aspects of product management.

If you want to be a good product manager, learn from the mistakes of Apple, including those related to the iPhone 3G S. Apple has produced some legendary products which have been wildly and there are many aspects of their product development process which product managers would be wise to understand and emulate. However, they are not perfect, as evidenced by less-than-stellar ideas like the Mac Mini and Apple TV, and slip-ups around launches of products like MobileMe. Their recently announced iPhone 3G S provides a few examples of why not to blindly follow Apple, and how to learn from their mistakes:

1. Product naming: The name for the original iPhone made sense — a phone + iPod, from Apple = iPhone. The iPhone 3G was a good extension; while 3G is more of a technical term, it is common enough parlance for consumers to understand the difference from the original iPhone. The addition of 3G described the main feature and benefit of the new model — speed. However, if the difference between the original iPhone and the iPhone 3G was speed, then the difference between the iPhone 3G and the iPhone 3G S is… more speed? Apple is unfortunately slipping away from their traditionally consumer-friendly naming scheme (e.g. MacBook vs. MacBook Pro) into the all-too-common tech-centric model numbers (e.g. TPS-8675309X). The lack of a clear differentiated name also will make it more confusing when the next version of the iPhone is released, and consumers have to differentiate between the different models when comparing versions, buying accessories, or seeking support. Apple unfortunately ran into this problem as well with the iPod, with new versions being unofficially being referred to as “generations” (e.g. “third-generation” iPod). This is not unlike the automobile industry, where a model name stays the same from year-to-year; however, unlike a car, Apple has been rather sly about naming each subsequent version and the differences between each “model year” are much less significant than the differences in an automobile from year to year. Since subsequent iPod models look physically similar, and since the software differences are not obvious at first glance, it takes some sleuthing to identify the type of iPod and whether a desired accessory is compatible. This has less of an impact on other Apple products like the iPod Mini, iPod Nano, and the various versions of the iPod Shuffle, since the visual differences between models is more obvious.
2. Hardware vs. software: Apple announced a number of new exciting enhancements with the iPhone 3G S, including the ability to copy-and-paste, search your iPhone, use peer-to-peer apps, and tether the device to your computer for roaming desktop internet access (provided you are in a supported country, of course). The only problem with these enhancements? They do not require an iPhone 3G S, only the iPhone 3.0 software, which is available for free for any iPhone owner. Apple extols the virtues of the new model, yet does not disclose clearly which features are in the new software versus those only available in the new hardware. Want to record Voice Memos? Any iPhone will allow that. But you also Want to use Voice Control? You’ll need the iPhone 3G S. By not providing a clear comparison of which features are part of the new software release and which require the new iPhone device itself, Apple risks frustrating “legacy” iPhone owners and iPhone 3G S owners alike. Existing iPhone owners may feel duped to learn that an exciting new feature actually requires a new hardware purchase, and iPhone 3G S purchasers may be upset to learn after the fact that an older (and cheaper) model would have provided the functionality they were looking for. While it is possible that Apple made this line intentionally unclear to persuade more current iPhone owners to upgrade to the iPhone 3G S, this would not seem to fit with the Apple culture. Other electronics manufacturers may take this route, though it is likely that Apple will have enough upgraders without having to resort to bait-and-switch.
3. Focus and Benefits: The iPhone 3G S is “The fastest, most powerful iPhone yet.” Great — how does that help me? If someone has yet to buy an iPhone, what benefits in the new iPhone will persuade them to purchase one? What segments is Apple trying to attract with this new model, and what features and benefits will win those customers over? Are there hoards of consumers out there who have been delaying an iPhone purchase simply because the device doesn’t start up apps quickly enough? The iPhone 3G S and associated iPhone 3.0 software seems to be more of a list of fulfilled feature requests than a focused strategy. Some features appeal to power users (e.g. 3 megapixel camera) while some appeal to those needing assistive technology (e.g. new Accessibility features) while some appeal to business users and those concerned about privacy (e.g. Find My iPhone and Remote Wipe). With a product like the iPhone, which is used so universally by so many different types of users, it would be hard to include something for everyone, which is all the more reason to focus on specific segments or personas. For example, to better penetrate the corporate market, features which provide additional security, auditing, IT oversight, and better enterprise integration should be added.

Will these flaws have a serious impact on sales of the iPhone 3G S? Not likely. Apple is such a marketing powerhouse and cultural icon that the success of the 3G S will be more about the product itself than its positioning or communication around the launch. And, despite these issues, the iPhone 3G S appears to be a reasonable improvement to an already dominant product. However, even the mighty Apple is not perfect, and product managers who ask and are asked “Why can’t we just do what Apple does?” should learn from the successes and missteps of the iPhone 3G S (and should also learn why you can’t innovate like Apple). No product is perfect, and product managers and product development teams should take any opportunity to learn from the successes and failures of others.

Translations available:

• Portuguese

If you want to be a good product manager, consider your market window as part of your product strategy. Often companies come up with what they believe to be a fantastic idea for a new product and there is a tremendous push to release it as soon as possible. There are usually two main reasons for this push:

1. The hope that the sooner the product is in the market, the sooner it will recoup its costs.
2. The belief that a competitor may also be trying to get a similar product to market, and you would like to have first-mover advantage.

To address these sometimes mistaken beliefs:

1. While a product obviously can not start recouping its costs until it is available for sale, simply releasing a product into the market is no guarantee that it will sell. There are countless examples of products which have rushed to market and flopped. Whether the product actually solves any buyer problems and whether those problems are ones which buyers will pay to have solved are much more important factors in determining the product’s likelihood of success. Even for useful and well-designed products, sooner is not always better. Some innovations are just ahead of their time, and first movers enter the market either before a large enough group of customers is ready to pay for the product, or before the cost structure makes it profitable for companies to produce the product at a reasonable profit level, or both. Sometimes there are external forces which slow down adoption of a technology. HDTV is a perfect example; while the first HDTV broadcast was in 1996, it was not until the mid-2000s that a critical mass of HDTV broadcasters emerged. In a classic chicken-and-egg problem, many consumers held off purchasing an HDTV until enough programming was available, so being an early entrant into the HDTV market may not have equaled quicker recouping of costs due to the lack of economies of scale and low sales volume.
2. Companies often scramble because of (sometimes irrational) fear that a competitor is developing the same product, with the belief that whomever is first to market will win. While there may be a first-mover advantage at times, there is no first mover guarantee. Additionally, there may be benefits to being the second mover into a market. Often the first entrant in a new market shoulders much of the burden at explaining the product and its benefits. While that organization must spend significant time and money educating the market about the need for this product, competitors can meanwhile be at work creating superior products and leveraging the technology innovations introduced by the first mover. Once the technology begins to gain more widespread market acceptance — thanks to the first mover’s marketing efforts — others can introduce their products with a better value proposition.

In Assessing Product Opportunities, Marty Cagan lists “ten fundamental questions” which product managers should be able to answer, including: “Exactly what problem will this solve? (value proposition) … For whom do we solve that problem? (target market) … What alternatives are out there? (competitive landscape) … Why now? (market window)”. It is this last question which is often overlooked when the others are answered relatively well. If there is a problem which customers will pay to solve, and there are no other alternatives, and the organization is well-suited to solve the problem, common wisdom is to launch as soon as possible. The argument is usually “Why wait?” vs. “Why now?”; unfortunately, “Why now?” is usually given minimal if any attention as a legitimate question.

Note that a market window is market-focused — not internally-focused — by its very definition. Often there are factors based on internal reasons which can dictate the development or launch of a product. Finance may push for launch to be delayed until the next fiscal year to avoid avoid early capitalization or depreciation of associated costs; development may ask to speed up the process because key resources are need on another project which is starting soon; tech support may want to wait to begin certain pre-launch planning because it is taking longer to hire the necessary additional support staff needed.

These are internal reasons why product development and launch, and unfortunately they often influence product planning and timelines. While it is easy to argue that they should not dictate the development and release schedules, the truth is that they often do, much more than product managers would like and ultimately to the detriment of the success of the product and of the organization as a whole. As much as possible, product managers need to be able to prove why there is a specific business case for hitting a specific market window. The stronger the business case is for that window, the more likely it is that the organization will adjust related areas to ensure the window will still be open.

The element of time is an important one in the product’s success and needs to be evaluated along with other valuable criteria. Looking at the market window strategically — versus being based on development and project timelines, or based on other internal factors not dictated by the market situation — may uncover some opportunities which can improve the product’s likelihood of success, helping ensure cross-functional support for hitting that window. Good product managers use time to their advantage and plan their product development and launch accordingly.

If you want to be a good product manager, get a good understanding of the problem before you try and solve it. Product managers and many others unfortunately assume the problem is evident and jump right to solving it. However, ill-defined problems lead to ill-defined solutions.

Albert Einstein purportedly said that, given one hour to save the world, he would spend 55 minutes defining the problem and 5 minutes finding the solution.

One of the most important aspects of defining the problem is to “size” the problem properly. If you define the problem too narrowly, your possible solutions may be very limited and uncreative. If you define the problem too broadly, your solutions may be out of scope and irrelevant to the business context.

For example, pretend you are a product manager for a technology company which provides communication solutions for consumers. You are looking to identify unmet needs which your organization may be able to solve. This may seem very straightforward — simply talk with customers and prospects to identify unresolved problems, right? However, different definitions of the problem could produce drastically different solutions:

• Taking a very narrow view — “people have problems communicating using email” — would lead to a very specific solution. Google’s GMail was developed based on observed problems users had with organizing and effectively using email. The scope was intentionally limited and focused on email and email alone.
• Taking a slightly broader view — “people have problems communicating online” — would lead to a wider variety of different insights and potential solutions. Twitter and Facebook are two examples of solutions which fulfill the need to communicate online. They are different ways of communicating — not just email, obviously — though the focus is limited to web-based solutions.
• Taking a very broad view — “people need a better way of communicating” — would open up an extremely wide range of potential solutions, not limited just to the web. This could include any of the above examples as well as other solutions like OnStar and push-to-talk on mobile phones.

This is not to say that any one approach is better than the other. How you define the problem depends on your organization, your market, and your overall strategy. An automobile company may define the problem space related to transportation in a different way than a conglomerate whose products range from bicycles and motorcycles to airplanes and subway cars.

Going too far in either extreme may be unproductive and inefficient in many situations. Defining the problem too narrowly may inevitably only lead to incremental enhancements when broader innovations are desired. Similarly, defining the problem too broadly may produce irrelevant ideas which do not fit with the corporate strategy and which would never be pursued by the organization.

Product managers need to avoid the rush to write requirements and add features without having a clear understanding of what they are doing and why. Even problems which may seem clear can benefit from a fresh look and a new perspective. Qualitative research can help refine and redefine issues products are facing and uncover new ways to look at the market — and it need not take months of work and thousands of dollars to be effective.

As with many apsects of product management, extra time and effort up front defining the problem can save time and effort down the road. Framing a problem properly can help product managers balance their innovation efforts, focus research and customer understanding, and help clearly define their product and portfolio roadmap.

If you want to be a good product manager, do not let your buy vs. build vs. partner decision unduly influence your go / no-go decision. Ultimately, the decision about whether to launch a product is a serious one, and the build / buy / partner decision is just one that needs to be taken into consideration.

Unfortunately, sometimes good product ideas can get stopped in their tracks because of a feeling that it will be too hard to build or partner for it, even though truly the investment would be worthwhile. Conversely, bad products can be brought to market because “it would be easy to do” by building or partnering, when the product maybe should not be launched regardless.

Think about when when you are planning a vacation — you usually think first about your destination, and then consider your mode of transportation for getting there. For example, if you live in Maine and want to take a vacation in January to a warmer climate, you would look at your different options for travel — plane, bus, train, car, etc. You would review your options to consider whether there is an affordable one which can fit with your schedule, and that may influence your decision on where specifically to travel, when, and whether you can go at all. However, if you found a bargain on a flight to Alaska, that would be irrelevant since your goal is to go somewhere warmer.

Unfortunately, this is the opposite of what often happens with product development. To build off the travel metaphor, even though a company may want to go to Florida, they find a partner who can get them to Wisconsin easily, so they decide to go there instead, even though that’s really not where they want to (or should) go.

The go / no-go decision for a product should not be made in a vacuum. There should be some consideration about whether the company is able to build the product internally, or whether there is potential for it to be created using a partnership, or whether there is an opportunity to buy a company or technology to enter into the market. Especially with the latter two options, this can definitely help improve speed to market, address areas which are not in the organization’s core competencies, and may present a more favorable cost structure at times.

However, ultimately the go / no-go decision should be based mainly on market-based considerations, such as:

• whether the market conditions are attractive (e.g. size, growth)
• whether there are unresolved problems which the product will address
• whether these problems are urgent and pervasive, and whether there are buyers who are willing to pay to have them resolved (to paraphrase the excellent book Tuned In: Uncover the Extraordinary Opportunities That Lead to Business Breakthroughs)
• whether the product fits the strengths and competencies of the organization
• whether this product could provide the organization with a sustainable competitive advantage

Product managers need to make sure they do not “put the cart before the horse.” Focus on the market need and the buyer problems, and then consider the different options for solving it. Whether you build, buy, or partner could have some influence on your decision, though it should not be the predominant factor.

If you want to be a good product manager, look to differentiate your product and avoid being a “me too.” Speed to market is certainly important, though it is almost always better to be later to the market with a better product than slightly quicker with something that does not stand out. Being first is good, though no guarantee. (Amazon.com was not the first online bookseller; the iPod was not the first portable MP3 player; Google was not the first search engine; Dyson was not the first vacuum; the list can go on and on…)

In Product Leadership: Creating and Launching Superior New Products, Robert Cooper offers some amazing statistics on “truly superior, differentiated products”:

One of the top success factors we uncovered is delivering a differentiated product with unique customer benefits and superior value for the user. … Our NewProd projects studies show that such superior products have five times the success rate, over four times the market share, and four times the profitability as products lacking this ingredient.

“Truly Superior, Differentiated Products” had an average 98% success rate and 53.5% market share, while “Me-Too” Products averaged an 18.4% success rate and 11.6% market share. Though the desire for quick revenue and immediate return within organizations is often strong, though there is good cause for launching the “right” product. In the end, the extra effort put into figuring out how to differentiate a product will be well worth the effort.

Cooper offers these “seven ingredients of a unique, superior product with real value for the customer”:

1. Meets customers’ needs better than competitive products.
2. Is a better-quality product than competitors’ (however the customer defines quality).
3. Has unique benefits and features for the customer.
4. Solves customers’ problems with competitive products.
5. Reduces the customer’s total in-use costs (better value-in-use).
6. Has highly visible benefits for users.
7. Is innovative or novel — the first of its kind on the market.

More importantly, he adds: “Note that product superiority is defined in the eyes of the customer!” While you may believe your product to be superior on one or more of these dimensions, it is ultimately up to the market to decide whether this is the case. Too often the view of product superiority and differentiation is different from those within the company versus those in the market.

It may be tempting to launch a follower product to ride the waves of a leader, without showing distinct differences in a product offering, product managers will be facing uphill battles. Look for ways to differentiate, to provide additional value, and to create a product that everyone else will try to copy.

If you want to be a good product manager, reinforce your communication though multiple avenues. Sure, it would be nice if you would only have to mention something once and have everyone in your organization understand, accept, and be able to re-communicate it. Unfortunately, that just is not possible.

As John Kotter writes in the classic Leading Change:

The most carefully crafted messages rarely sink deeply into the recipient’s consciousness after only one pronouncement. Our minds are too cluttered, and any communication has to fight hundreds of other ideas for attention. In addition, a single airing won’t address all the questions we have. As a result, effective information transferal almost always relies on repetition.

Inconsistent and infrequent communication leads to confusion and frustration. Product managers need to work with others within their company to prevent this from happening and deliver consistent messages in various formats.

Whether you are providing details about an enhancement in your next product release or a change in pricing strategy, you want to make sure that the important individuals within your organization receive and understand what is happening and what it means to them. As a product manager, this means communicating this important information clearly, consistently, and often through multiple channels. Some people learn better when they read it, others when they hear it, and others when they see it. Most need to hear it multiple times through multiple channels in order to really process the details and understand what it means to them.

Even simple changes or details can be easily misconstrued or misinterpreted. It is not enough to just provide the information; product managers need to provide additional resources to ensure that the message sticks. Follow up an email to your sales force with additional documentation to which they can refer later. Deliver a presentation to your support staff, then make sure to post the slides on your intranet. This technique should be applied when communicating externally as well — follow up a press release with a blog update, a webinar, and direct communication to your key customers.

While this sounds like a basic suggestion, it is so often overlooked and can nearly always be improved. Think about how you receive information from others within your organization. Do you always learn all of the details which you need to know from HR? Do you receive information from Finance in a timely fashion? Do you hear things through “official” channels or through hallway conversations? How an organization communicates information about its products is often related to how it communicates in general. If an organization has good communication and information dissemination practices in place, it is easy for a product manager to follow those when providing product information. If the organization has other communication issues (and most do), a product manager will need to work even harder to combat those ingrained tendencies.

Translations available:

• Portuguese

If you want to be a good product manager, make your product solve a specific problem for a specific type of customer. It may sound appealing to make your product attempt to solve every problem for every type of customer, though in most cases, trying to make it everything for everyone usually results in a product that does nothing for no one.

For complex technology products, many options provided are rarely — if ever — used. Additional complexity added to attempt to appeal to different types of users usually just makes the product more difficult to use for those core consumers. Also, when the product does not focus on solving a specific problem for a specific user, it becomes difficult to communicate the benefits to the market. Either the message is scattered — “This fixes all of your problems, no matter who you are!” — or it results in disjointed messages for different target markets.

More important to consider, however, is the fact that consumers may seem to value products which focus on one specific problem over products which focus on many. The article “Jack of All Trades or Master of One” summarizes new research by Alexander Chernev, professor of marketing at the Kellogg School of Management, and suggests that products which specialize are perceived to be superior to others, even on attributes where the products are in fact equal:

Chernev found that a product specializing in a single attribute is perceived to be superior in that attribute relative to an all-in-one product having multiple features. This happens even when the two alternatives are clearly described as being equivalent on that attribute. For instance, consumers expect whitening-only toothpaste to whiten teeth better than toothpaste that both whitens and prevents cavities…. Therefore, when evaluating choice sets comprising both specialized and all-in-one options, consumers tend to consider the overall performance of the alternatives to be equivalent. This leads them to draw two types of compensatory inferences: compensatory devaluation, which lowers the perceived performance of the all-in-one option, and compensatory polarization, which enhances the perceived performance of the specialized options on their differentiating attributes.

Even when two products are in fact equal in a given area, there is the perception that the focused product is superior in that area. For product managers, this means that it may be beneficial to identify the most important attributes to a customer segment and focus the product development and marketing around that attribute, rather than trying to improve and promote “across the board.”

It is worth noting that this study did not take into account price, though a subsequent study (also summarized in Jack of All Trades or Master of One) investigated how price can change and improve perceptions of all-in-one products. Still, all other things being equal (including price), there is good evidence to suggest that focused products are perceived to be superior.

One needs only to look at the proliferation of specialized products in the marketplace to see evidence that this strategy is effective. (After all, if these products were not profitable, would they continue to be produced?) All-in-one cleaners now have stiff competition from cleaners for very specific purposes. “Every pain” medicine is placed alongside medications for every known type of pain. General web portals which can serve many user needs have to contend with start-up web applications which focus on specific, common tasks.

This is not to say that an all-in-one strategy is always bad. Product managers can still choose to pursue an all-in-one strategy; they just must be aware of the impact it may have on the perceptions of customers. Even then, an all-in-one product should be that way because it provides value and solves specific problems for the customer, not just all-in-one for the sake of being all-in-one.

Translations available:

• Portuguese

If you want to be a good product manager, consider all aspects related to any add-on features. A product manager is not only responsible for identifying what needs there are in the market. The product manager must also figure out how those needs should be filled by new or existing products.

There are many valid reasons to include something as an add-on to an existing product, including: to utilize an existing platform for lower cost and broader distribution yet still allow for additional revenue; to provide capabilities for one customer segment while not overwhelming another; or to leverage brand recognition while expanding the product portfolio. Usually product development teams spend a lot of time deciding whether or not to include something as part of the standard product, and much less time determining the steps for how someone would obtain that add-on. In fact, how easy it is for the customer to enable the feature or buy the add-on can be a big determinant of how successful it is.

Imagine that you have a great new feature for which you have validated the market need and determined that the best approach is to allow this to be added on to an existing product. This could be a home networking option for your cable modem. It could be an extra section of content on your web site. It could be an adapter that can be added to a jogging stroller to accommodate smaller children. If you want to launch these as add-ons, what do you need to first consider?

1. How will customers find out about the option? It does not matter how beneficial the add-on may be if customers do not know that it is available. Rather than just “build it and they will come,” product managers need to make sure that customers of the existing product are aware that the options are even available.
   • For example, jogging strollers usually are designed for toddlers, though some provide options to accommodate infants. Customers shopping for a jogging stroller need to be informed whether a particular stroller can accommodate an infant, and whether there is an add-on which will allow for use by infants. If it is unclear whether a stroller is designed for an infant, or whether an adapter is available, then customers may inadvertently overlook a stroller which meets their needs.
2. How will necessary details be provided to customers? The level of detail provided about new standalone products is often more than provided about enhancements to existing products. If the product team treats an add-on as just an enhancement to an existing product, the result may be a shortage of information for customers viewing this as a separate purchase or setup. Product managers need to understand the decision process that customers will go through and make sure that the information is available and sufficient.
   • For example, if you are adding a new section of subscription-only content to your web site, you need to provide a way within your existing site structure to promote and explain this new content. If the rest of the site consists of free content, then this provides a unique challenge of having to explain the value proposition to customers. Making customers available of the option is simply the first step; in this case, customers may require details around pricing, availability of archives, and various access options — all much more than would be provided were you just adding another section of free content.
3. How will customers enable the option? Once customers are aware that the option is available, it must be straightforward for them to take advantage of it. Convoluted and cumbersome processes will reduce the number of customers taking advantage of this capability. The process for enabling the option needs to be part of the consideration when creating the option in the first place.
   • For example, many Internet service providers include add-on options such as wireless home networking. If it is easy and quick for a customer to set this up on their own, this could be a big benefit. However, if this requires contacting customer service, scouring your router for technical details, and waiting for the option to be enabled by the service provider, these steps may negate the potential benefit and turn away prospects.

Additionally, product managers need to think ahead about how they will segment customers who utilize this option in the future. The web site in the example above has a simple way of communicating to customers who have purchased the subscription-only content, while the Internet service provider may have more of a challenge identifying customers who have enabled the wireless home networking option. Part of the product requirements would likely be to be able to identify customers who have enabled this option so that any necessary billing, communication, and support can be addressed.

Good product managers not only identify the customer need which is being addressed — they realize that in order to really fulfill that need, customers need to be aware that a solution is available, have the appropriate information about the solution, and have an easy and smooth way of taking advantage of the solution.

If you want to be a good product manager, proactively seek out feedback rather than wait for complaints. Lack of complaints does not mean that you have a fantastic product — it just means that you are not getting any complaints.

Waiting for customers to complain is problematic for several reasons:

1. Not all customers complain. Think about all of the products you use on a daily basis, and the problems you encounter with all of them. There may be a confusing button on your cell phone, a strange error message on your online banking site, or a slippery grip on a kitchen gadget. How many times have you taken it upon yourself to contact the organization responsible for that product? Despite the multitude of different ways to complain — from the traditional methods like contacting the company directly, to more modern methods of voicing your frustration on Twitter or a product review site — most customers do not make the effort to send this feedback directly or indirectly to the company. A product manager simply hoping to hear from customers with problems is only going to hear about a fraction of the problems from only a fraction of the customers. For every customer who vocally complains, there are likely tens or hundreds or thousands of others who are silent.
2. Lack of complaints may mean lack of customers or users. While we would like to think that lack of feedback means lack of problems, it is often that lack of feedback means lack of experience on which to provide feedback. When a product manager adds a new feature to a product and does not hear any complaints about the feature, he may assume that the feature is a success and the fact that customer service has not received any complaints is because it is working smoothly. Unfortunately, it could be just as likely that no one is using the new feature, and thus no one has any experience about which to complain. If there are a small number of customers using the new feature, relying on their complaints alone may provide very skewed feedback.
3. By the time someone complains, it is usually too late. While the previous two points are worth noting, this is truly the most important reason to not simply wait for complaints. For physical products, changes to a product after it is in the market can be extremely expensive and time consuming to rectify. From a purely financial standpoint, it is the responsibility of a product manager to attempt to produce the best product and thus avoid costly changes. However, even for web-based products which can be changed very quickly and cheaply, waiting for customers to complain is backwards approach to product development. Sure, it may be gratifying on the surface to say that you are able to respond quickly to problems that customers raise, but wouldn’t it be better to prevent these problems in the first place? Would you rather buy a car from a company who listens to your complaints and reacts when your car has problems, or would you rather buy a car from a company who produces a car which will not cause you problems and will not cause you to have to complain?

Ultimately, no matter how hard an organization tries to address problems and meet needs, people will complain, and product managers can benefit from listening to and understanding those complaints. However, when a legitimate complaint is lodged, rather than just reacting to it, product managers should ask, “How did we not know about this earlier?” Is the complaint related to something that the team should have known about? Would a better understanding of the customer needs have helped prevent it? Would better design or more usability testing have uncovered the underlying problem? Did a defect make its way into the final product? Did we know about the problem and just hope that no one would notice? How did it come to this — that a customer had to complain in order for us to realize something was not right?

Complaints are a valuable source of information which can be used to help improve your product, though they are only one source and should be used carefully. Product managers need to be proactive at gathering feedback from customers and prospects, though activities like usability testing, Win/Loss analysis, site visits, observational interviews, and other types of qualitative and quantitative research. Rather than just waiting for complaints and responding to them, product managers need to be focused on preventing them from occurring and getting to the root cause when they do appear.

Translations available:

• Portuguese

If you want to be a good product manager, adapt your practices to the organization and situation. Product management is not (yet) an advanced science. Instead of laws and rules, we have guidelines and experiences to guide us. While it is in the best interest of a product manager to identify and follow best practices whenever possible, these are not absolute rules. What works effectively in one organization may not work for another, and a good product manager needs to identify what will make him or her most effective and change tactics accordingly.

Marty Cagan argues that the “product management model” which may work best in a company depends on several factors, including the type of product, the product development process, the role of product management, the size of the organization, and the company culture. Beyond that, it is important to realize that these elements are interrelated as well. For example, the “best” product development process for an organization will depend on these other factors. What works well for a large, formal company with established product management may not work well for a small informal startup where product management is just getting started.

Many product managers — especially new ones — are looking for a strict guide to follow which will lead them to product management success. Unfortunately, we do not have one yet, and it seems unlikely that one will be established in the near future, given the multitude of variations that exist. Those who expect to be given a prescribed plan are often frustrated at the lack of direction and afraid they are failing in their product management duties.

As a product manager, you should not look for the perfect model, or feel guilty if you are not doing things the exact way that the experts / consultants / authors / bloggers (including this one) prescribe. Instead, focus on understanding the needs of the organization and the market, and put yourself in a position to make the most impact.

• Maybe the type of requirements document that works “best” for your situation is different than what the training prescribed; what really matters is whether it will meet the needs of the engineers and the team.
• Maybe your Win/Loss Analysis can not follow a traditional structure due to the nature of your customers and how they make purchase decisions; what really matters is whether you can collect the relevant data which will help improve your product and sales process.
• Maybe you are not able to tackle all of the aspects of your chosen product management framework at once; what really matters is whether you are focusing on the areas which will have the biggest impact initially.

These should not necessarily be looked at as faults that need to be corrected. Instead, they could just be the nature of the situation and represent the best possible response.

Regardless of the situation, product managers should still focus on continuous improvement, possibly even developing a plan which addresses areas on which to focus. A good product manager will concentrate less on comparing himself or herself to other product managers, and more on what is best for the company, the product development team, the market and the customers.

If you want to be a good product manager, realize that technical superiority only matters if it provides value to your customers. Whether your solution is “better” than the status quo or the competition is a judgment made by the market, not by your engineers. Technological innovation is worthwhile when it can be translated into benefits for the customer.

New technologies always have benefits, and they almost always have side effects as well. Technologists often only focus on the benefits of the technology, and either do not consider or do not understand the importance of the consequences. For example:

• A company may have a new technology that preserves sound quality better than MP3s and produce smaller file sizes than ACCs — qualities that they believe make it the “best” file format to use. However, if it is not compatible with iTunes, then many customers would not regard it as the “best.”
• A manufacturer of wireless networking wireless networking equipment may provide a way to improve signal strength over long distances, making it desirable for people with home networks in large houses. However, if the technology causes increased interference with other wireless devices (e.g. cordless phones), then many consumers would not see this as a technological advancement.
• A new battery technology may provide longer battery life for laptop computers, yet cause the battery to weigh more. Is the technology “better” or not? Different customer types will answer this differently. Those who value battery life over weight will appreciate the improvement, obviously. For others, the answer will depend on the extent of the changes. A certain type of customer may put up with a battery which is heavier by 4 oz. if it means an extra hour of battery life, though they may not tolerate a battery which is heavier by 1 lb. if it means only an extra 20 minutes of battery life.

In all three of these examples, the concepts of “better” or “best” technology are in the eye of the beholder. Engineers will often appreciate advancements in technology that can not necessarily be explained or translated directly into customer benefit. While there ultimately usually is some value to the customer, it may require a game of connecting the dots to understand the advantages.

Ultimately, evaluating technological improvements for value requires understanding customer needs, preferences, and problems.

• In the digital music example, the product manager should know much of the current and potential customer base uses iTunes to manage their music, and whether customers value the benefits of this new technology (better sound, smaller file sizes) over the benefits of iTunes.
• In the wireless networking example, the product manager should have spent time with customers in their homes, understanding how their networks are set up and what other devices the customer uses. This would help the product manager define the requirements for implementation of a new technology, such as 90% signal strength over 50 ft. and no interference with 900mhz devices.
• In the battery example, the product manager should understand the different customer types, what attributes they value, and the importance of each attribute relative to each other. Knowing what customer types would value battery life over weight, and what sort of trade-offs they are willing to make, the new technology could be positioned and marketed appropriately for the proper customer segments.

Whenever someone proposes a technological improvement that they content is “better,” product managers need to probe further to understand what makes it better. Why is it superior? How will customers benefit? What are the criteria which customers value, and how will this impact those criteria? Will it improve one criteria at the expense of another? Does this tradeoff add or remove value from the product? By going through this exercise, rather than just accepting the assertion that it is “better,” a product manager can ensure that technological changes are adding value to the product and improving it in the mind of the customer.

Translations available:

• Portuguese

If you want to be a good product manager, properly analyze and choose the right partners and strategic alliances. Product managers put so much thought into many important areas of their product, yet often the decision about whether a product or an aspect of it should be built, bought, or developed using a partner is given short shrift. This is problematic, as it often is one of the most crucial parts of the customer experience.

When a customer purchases or uses your product, their satisfaction and delight is not just tied to the product itself. The entire experience influences what they think of your product, including things like where they purchase the product, how it is packaged, the quality of the components, and other products with which yours interacts. However, product managers — and many others within an organization — narrowly define the “product” and do not take into account these other aspects. What could be otherwise a fantastic product could be ruined by making the wrong build / buy / partner decision.

While there are certainly companies which would be “bad” partners for any product, in most cases a “bad” partner is simply one where there is a misalignment of priorities between your organization and theirs. A quality-focused product will partner with a low-cost (and lower-quality) vendor; a company known for its customer service with align itself with an organization with a bad customer service reputation; a product designed for the value-conscious consumer will be sold through a full-service (and higher-cost) distribution channel.

These ill-conceived partner decisions may be made for a number of reasons, including everything from lack of proper knowledge about the potential partner to an executive who has a pre-existing relationship with the desired partner. Regardless, they stem from a lack of proper analysis of the situation.

To make sure you are aligning yourself with the right companies, make sure you understand why you are choosing to partner in the first place. (This Build, Buy, or Partner (PowerPoint presentation) from the NorCal PDMA provides a great overview of that decision process.) You must first make sure you are clear on why you are choosing to partner, not with whom you are choosing to partner. While an attractive suitor who approaches you may initially spark your interest in a partnership, you need to evaluate the overall potential for partnership first before considering this specific opportunity.

Once you understand why you are choosing to partner, you need to evaluate what you are looking for in a partner. There are a number of questions that you need to ask before committing to an agreement, including

• What are your expectations for the partner?
• Do you want a long-term strategic alliance or a quick integration?
• Are their values aligned with yours?
• How do their capiabilities fit with your distinctive competence?
• Is one side benefiting more for the partnership than another?

These questions and others can help you objectively evaluate a partnership decision. Obviously, there are additional steps after evaluation — discussing monetary aspects, agreeing on terms and conditions, and negotiating other details of the alliance. However, a product manager should not jump into those details without first understanding the higher-level questions. Once the “big picture” is clear, negotiating the fine print of the agreement will be much more straightforward. While there is often a desire to rush into the decision — one main reason for choosing a partner is to improve speed to market, after all — a more regimented approach will ensure that any strategic alliance is a proper fit for your product and your market.

Translations available:

• Portuguese

If you want to be a good product manager, do not immediately solve every problem which presents itself. It is often tempting to fix an issue as soon as it appears, though there are many good reasons to not rush to address problems:

1. If you fix the problem right away, you may not be addressing the underlying issue that caused the problem in the first place. In fact, in most cases, there is a root cause which is likely not visible on first glance. This applies to many areas in product management, most notably in addressing requests from customers. This has been discussed here in several different posts, including Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.
   However, this concept applies to other areas of product management as well. There are many times when “points of pain” which are readily apparent can be traced back to root causes. Challenges within the product development process may be attributable to several factors. For example, releasing a product with many defects may initially appear to be a problem easily solved by adding additional Quality Assurance resources, though the real problem may be lack of appropriate details in product specifications. As another example, disagreements about prioritization for development work may cause many to push for a voting system, though the disagreements may be caused by an inconsistent view of the vision, strategy, and roadmap.

   In medicine, there is a saying that doctors should seek to treat the disease, not the symptoms, and product managers would be well served to follow this advice as well.

2. Letting the problem subsist for a period of time may be the only way to get others to realize its severity. Parents often tell tales of how their children learned what not to do — not to touch a stove, for example — by letting the children try it once and learn for themselves that it is a bad idea. A similar approach can be taken in product development. Whenever you try to convince people to change or implement new ideas, you need to show them why the changes you are proposing are needed. Without understanding the need for change, people will cling to the status quo.
   For example, you may want to implement a requirements management tool because of the problems you see with how requirements are managed. Rather than spending all of your energy telling people why it is needed and doing demos of the various products, you may be better off letting the current requirements process show its weaknesses. Perhaps you have a new version of your product which is close to release, yet you know that there are requirements which were likely lost along the way. Instead of insisting that the release be held up, you can foreshadow the issues before the launch and let the product be released. If you are correct, it will soon be apparent to all that requirements were mistakenly never implemented because of the faulty requirements management system.

   This tactic needs to be used carefully. As product manager, you are still responsible for the product in the end, even if you are trying to teach your team a lesson or tell them “I told you so.” However, in many cases, it is possible to use smaller projects or specific aspects of the product as examples which can prove your point and make the case for change.

3. Problems may not be as severe as you originally thought. Often, when an issue presents itself — defect in the product, complaint from a customer, argument in a meeting — there is a rush to resolve it immediately. A product manager will often break focus from the really important things — strategy, roadmap, getting out of the office to talk with customers — and instead spend energy on “fire fighting.”
   However, issues are rarely so important that they must be resolved immediately, and seldom are they more important than the larger strategic activities on which a product manager should be spending his or her energy. In the heat of the moment, every problem appears to be major, though with time, the importance of most usually diminish. The truly severe problems will become apparent quickly, and this will allow you to focus more attention on the major issues rather than the crisis of the day.
4. More time gives you more opportunity to find the right solution. In a rush to find answers before we even understand the full extent of the problem, we often choose the first idea which comes to mind. While this may be an acceptable solution, with more time to understand the issue, look for underlying problems, and brainstorm solutions, it is likely that a better solution can be determined. While more time does not guarantee more or better solutions, it is at least certain that you will not have fewer ideas or worse solutions if you provide more time to consider your options.

The next time a problem comes along, resist the urge to take immediate action. Take a strategic — not tactical — approach to problem-solving by evaluating the issue and considering possible underlying causes along with the overall severity. By not responding immediately to every issue, you will spend less time putting out fires and more time on the true value-adding strategic aspects of product management.

Translations available:

• Chinese
• Portuguese

If you want to be a good product manager, measure the impact of the product changes you implement. Product managers need to be constantly evaluating the changes being made to a product and measuring whether they were successful.

Too often, product managers implement new features, functionality, or make other changes to a product without a true understanding of why these changes are being made. The product manager may think he or she has a logical reason for requesting the change — a specific customer asked for the feature, an engineer suggested the change, senior management requested it — though that is just part of the picture.

Even if there is a legitimate reason why the change should be made (and good product managers should know that none of the above reasons are truly legitimate reasons in and of themselves), the product manager has a responsibility to go several steps further and quantify the impact of the changes. Though this may seem as though it is creating more work for the product manager, it in fact will make his or her job much easier. Product managers need to be able to quantify “success” for any given change, rule out changes that are less likely to be successful, and measure all work which is implemented. This allows the product manager to ensure a higher likelihood for success and also show the impact of the change to gain support for future changes.

Besides just coming up with an idea and implementing it, there are several steps product managers need to go through before engaging in product development:

1. Define the expected impact of the changes. Different products and different changes will have different impacts, though some popular measures are
   • increased usage
   • increased revenue from existing customers
   • new customer acquisition
   • improved customer retention rate
   • improved customer satisfaction
   • increased market share
   • references to change in blogs, media coverage, or analyst reports
2. Establish goals for the changes. Once you have defined the specific measures, the next step is to explicitly state what you hope this change will achieve. Good goals are SMART goals (or MT goals, if you prefer), making it clear whether the goal was met or not.
3. Determine how you will measure the impact. Though you may know the impact you expect or hope to see and have a specific quantitative goal in mind, you must be able to measure it to evaluate its success. For example, if you are considering adding a new feature to your web site, and your goal is to have 10% of your customers using the feature of the website within 30 days of it being released, you need to have web analytics in place to measure whether the goal is met or not. Though this seems obvious, often times work required to measure the impact of a change is not considered until too late in the development process for measurements to be put in place, or, even worse, after the change has already been implemented.
4. Measure the impact and objectively evaluate. After the change is implemented, compare your actual results to your expected results. Were the results achieved? Why or why not? What could have caused the results? Are there additional changes which are needed? What was done well that should be replicated for future product changes? What did you learn which could improve your success in the future?

Many may resist this process for various reasons. There are several common objections and responses:

• Objection: “There is just too much work required to go through all these steps for each feature! We can’t define the impact, establish goals, figure out measurements, and then actually measure everything we do! If we did, we would only be able to release a fraction of the number of changes that we do now.” Good! The job of a product manager is not to make changes to the product just for the sake of making changes. Products must have goals, and the product manager must focus on meeting and exceeding those goals. Adding new features is not a goal; increasing revenue is a goal. If this process slows the process down a bit, that may be a good thing. Instead of money being spent on 10 mediocre new features, money may be spent on 1 good one which has a much bigger impact than all 10 mediocre ones combined.
• Objection: “We don’t want to set goals if we’re not sure we can meet them.” If the goal of a new feature is to increase revenue by 10%, and your new feature increases revenue by 5%, you may not have reached your goal, though you still increased revenue by 5%! Sure, it fell short of the target, though it is still well above where you were before. Instead of criticizing the inability to meet the goal, evaluate whether the goal was realistic, what could have been done differently to meet the goal, what changes can be made now to get to the goal, and what can be done different in the future.
• Objection: “We don’t have a way of measuring the impact of our changes.” Some changes are harder to measure than others, and it may not be practical or worthwhile to measure every single minuscule product change. However, without metrics and measures, product managers are “flying blind.” Product changes require an organization to investment time, money, and other resources, and there is an expected return on that investment which — sooner or later — you will need to demonstrate. Establishing and tracking metrics will allow you to create a better product and identify problems earlier. It is in the best interest of your product, your organization, your customers, and you as a product manager to determine how those measurements can be put in place.
• Objection: “We can’t agree on what the impacts and goals should be.” If that is indeed the case, then avoiding these steps completely will not solve that problem. This process may be difficult to start, though a team will only get better at it over time. It may not be possible to get complete agreement on all of the details, though going through the process will identify where goals are not aligned. For example, the marketing manager may want to implement changes which will generate more new customers for a web application, while an engineer may want to implement changes which will make the application run faster. In this case, getting even general agreement on areas on which to focus would be beneficial.

Still, in light of these objections, there is value in going through the first 2 steps outlined above even if there is no way to effectively follow through on steps 3 and 4 just yet. Discussing expected impact and defining goals with the relevant stakeholders is an incredibly useful exercise. Rather than just delving into the details of how a change will be made, as often happens, you are really focusing the conversation on why the change should be made at all. Getting in the habit of going through this process is beneficial, even if it is not possible to completely track or follow through on measurements, as it can establish the mindset for approaching product development going forward.

Implementing metrics and measurements may be an intimidating and overwhelming step for a product manager. However, if done properly, it can potentially lead to enormous improvements in the product. It will make product development less contentious and more evidence-based, leading to a more efficient and effective management process. Additionally, it can make you as a product manager more effective, since your time and efforts are focused on areas which will provide value, and you will be able to show the value you have created — a true measure of a good product manager.

Translations available:

• Arabic
• Portuguese

If you want to be a good product manager, try to deliver the fewest features which will provide the most value. Customers buy products because of the needs that the product fulfills and the problems the product solves. Features in and of themselves are useless — they exist to fill a need. Customers will find product features valuable only if those features satisfy a need and if the act of filling that need is something which is valuable to the customer.

Unfortunately, product managers often approach this problem the wrong way. They will create a long list of desired features and then get estimates from engineering on how much effort each requires. The most important features may take the most amount of effort, so, in the hopes of getting more features more quickly, a product manager will forgo the most time-consuming — and often the most valuable — enhancements to the product. Instead of a few valuable features, the product gets a larger number of less consequential additions.

Rather than simply counting the number of features or the amount of enhancements, product managers should evaluate the ratio of value to effort and focus on obtaining the most value for the customer with a given amount of effort. Product management is not about delivering the most — it is about delivering the least. As Marty Cagan of Silicon Valley Product group writes in Great Products by Design (which has been quoted here before and will likely be quoted here again):

The job of the product manager is to identify the minimal possible product that meets the objectives and provides the desired user experience — minimizing time to market, user and implementation complexity.

Instead of adding more features, product managers need to make sure they have the right features in their product and consider removing features when appropriate. By creating a product that provides the most value for the least amount of effort, a product manager will produce a product which is easier to sell, support, and maintain, and ultimately deliver more value to the customers and to the organization.

Translations available:

• Arabic
• Chinese
• Portuguese

If you want to be a good product manager, understand unmet needs and use that insight to drive requirements. A product manager who just “gathers requirements” is doing nothing more than taking orders or documenting requests. Good product managers add value to their product by understanding the problems and needs behind requests.

Requirements gathering is an activity often thought to be the cornerstone of any project. The mentality comes from traditional information technology projects, where “the Customer” who was funding the project appeared to know exactly what was needed, and an “analyst” would document the requirements. Successfully gather the requirements, document them, and get sign-off, and the end product will be guaranteed to meet the customer’s needs — or so the theory went.

Of course, this theory fails because “customers” usually do not know exactly what they want and can rarely understand or articulate what they really need. They may have an accurate picture of some of the obvious needs, though often they do not recognize the underlying problems nor are they in a position to come up with the optimal solution. For example, a customer may request a small change in a 10-step process, though someone in a position to better analyze the problem may be able to figure out a way to reduce it to 3 steps — or eliminate the process altogether.

Additionally, gathering requirements from various parties will inevitably lead to conflicting requirements. One type of end user wants a simple Google-like interface on the home page, while another wants lots advanced search features; one internal department wants to use the home page promote what’s new on the product, while another wants to market other solutions which the company offers. These requirements are impossible to all fulfill simultaneously, so the act of gathering them in and of itself has left you no better off than you were before. Additionally, by asking for “requirements” from each group, you have set up each group for disappointment when they eventually realize that their “requirements” were not and can never be met.

A product manager — or anyone — who is just focused on “gathering requirements” misses the greater value that their role can bring. Simply put, there is no value in a product manager who just gathers requirements. The product manager must add value through insight and understanding, by making decisions about priorities and focus. Those who gather requirements just document; the product manager must

• Set the vision for the product: Which customers and internal stakeholders are important to the product’s success?
• Prioritize the different customer needs: When needs conflict, whose are more important?
• Determine which needs will and will not be fulfilled: Does this fit with the vision and strategy for the product?

Good product managers do not just gather requirements — they understand unmet needs, existing problems, and opportunities for improvement, and they then use that information to determine the requirements for the product.

Translations available:

• Portuguese

If you want to be a good product manager, delegate tactical activities to allow you to spend time on the strategic aspects of the job. Effective product managers pass on product knowledge and responsibility for tactical decision-making as much as possible to others on the product development team. By leveraging the rest of the team, the product manager can focus on the strategic role of product management.

It is difficult for many product managers — especially new product managers — to effectively balance the strategic and tactical priorities of product management. With so many competing priorities, the minutia and day-to-day tends to take over. To extend a common metaphor, it’s not just that product managers sometimes focus on the trees instead of the forest — they go so far as to end up focusing on a specific piece of bark.

While it is easy to say that product managers should be more strategic and less tactical (see Spend your time in the right places, for example), actually accomplishing that is a significant challenge. Pragmatic Marketing recently released the free ebook “The Strategic Role of Product Management,” by Steve Johnson, which describes why product management is a strategic role and why product managers need to think and act strategically. Buried in the “Final thoughts” section is this beautiful nugget of wisdom (emphasis added):

Product management is a strategic role. Yet as experts in the product and the market, product managers are often pulled into tactical activities. Developers want product managers to prioritize requirements; marketing people want product managers to write copy; sales people want product managers for demo after demo. Product managers are so busy supporting the other departments they have no time remaining for actual product management. But just because the product manager is an expert in the product doesn’t mean no one else needs product expertise.

Product managers should take heed of this last sentence. Think about all of the tactical activities in which you engage — documenting details, answering questions, describing functionality, responding to feedback, tracking down responses, and the like. How much of your time is taken up by these activities? Why are you engaged in them? Is it because

1. you are the only person in the company who knows how?
2. everyone else is busy and you are the only one who has free time?
3. they are so important that they must be done by you and only you?

The answer to these questions is probably an emphatic NO in most cases. The real reason that product managers are engaged in these activities is because they have done them in the past, so others assume they will do them in the future. Every time a product manager writes copy for marketing, or conducts a demo for sales, or investigates some technical issues for development, the product manager creates the expectation that he or she will do that in the future. Obviously, there are some occasions where this may be appropriate, However, the vast majority of the time, the product manager can and should be giving the necessary direction, context, and guidance to allow other people to accomplish these tasks themselves.

Most product managers do not have staff reporting to them, so it is not necessarily as easy as delegating tasks to a direct report. Instead, product managers need to leverage others and teach them to be self-sufficient. This is not to say that product managers should ignore requests or haphazardly push off their responsibilities, of course. Instead, product managers should look to make those around them more effective by providing them with the tools, information, or resources they need.

Every time you as a product manager are presented with a task, ask yourself these questions:

• Is this helping to advance the product strategy?
• Does this support one of the high-level goals for my product?
• Is there anyone else within the company besides me who can accomplish this task (e.g. answer this question, investigate this problem)?
• Is this something that has come up before or is likely to come up again?
• Is this a valuable use of my time?

It’s never easy saying “no,” though it may be easier to look at it this way — every time a product manager says “yes” to something that is tactical and routine, they are saying “no” to something that is forward-looking and strategic. Which would you feel more comfortable telling your boss — or the CEO — that you said “no” to?

So what do you do with the tactical activities — those requests for copy writing, operational meetings, responses to customers, and discussions of detailed product minutia? Ask yourself — and others — whether they are really necessary, or at least whether it is really necessary for you to be included. Going back to the three questions posed earlier, look at why you are engaged in tactical activities:

1. If you are the only one who knows some vital piece of information, figure out some way to rectify that. Document it, communicate it, teach it to others, pick someone to transfer knowledge — find some way to make sure that someone else has the information. Beyond just providing better use of your time, this can be vital for business continuity and succession planning.
2. If everyone else is claiming to be busy and is offloading responsibilities, the same can be doubly true for a product manager. Help create ways for people to answer questions or streamline tasks on their own, rather than passing on their additional work for you.
3. If there really are activities that appear to be vital enough to be performed by you and only by you, analyze those activities closely. Some may seem critical at first glance, though upon review you may notice that they are not as important as originally thought. Also, other people may be turning to you because they think you want to be involved, or because they think you would be offended if you were not consulted. Just because someone else thinks a task is crucial enough that it must only be done by you does not mean that you have to agree with them.

Lastly, if you are involved in these activities only because you have always been — well, then make it a resolution to stop today! The more product managers can think about their role as being strategic and market-focused, the more they can add value to the organization and to customers. Effective product managers help create more product expertise within the company. This gives the product manager as much time as possible to focus on the reason the company created the position — to add value by creating and improving market-focused products.

Note: This post is part of a Pragmatic Marketing’s BlogFest. Other posts as part of previous BlogFests include:

• Understand your product’s domain (part of the BlogFest on Everyone needs to know what we do here)
• Use conferences to learn, not to sell (part of the BlogFest on Why Demo at Trade Shows?)

Translations available:

• Portuguese

If you want to be a good product manager, be comfortable being uncomfortable. Product management is tough work. Some aspects of it are fantastic, and some aspects of it may be dreadful. Just because you may not like one part of the job does not mean you can avoid it. No matter how experienced or skilled you may be, there are some parts of the job you will like better and be better at than others. A good product manager can not avoid the less favored parts of the job just because they are challenging or painful to address.

What might make a product manager uncomfortable? There are some things that probably most would agree are difficult and not the most fun to handle:

• Delivering a presentation to senior management about why your product launch is behind schedule
• Confronting a developer who did not follow the requirements which were agreed upon
• Trying to appease an important — and now upset — customer who is considering taking their business elsewhere

There are other tasks that may be uncomfortable for some product managers and enjoyed by others:

• Analyzing the product’s revenue and sales forecast — Great if you love number-crunching; horrible if you feel less confident in your finance abilities
• Delivering a booth presentation at a trade show — Great if you love giving the same 5 minute pitch over and over again; horrible if you hate repetition and can not focus when you have a transient audience
• Engaging in business development discussions with a potential partner — Great if you know the potential partner’s strengths and like brokering deals; horrible if you are less aware of the potential partner’s business and are not an experienced negotiator

Product managers do not need to excel in every aspect of their job to be successful. However, there are key responsibilities that they need to accept as part of the position. Many of these responsibilities will make them uneasy, as they are not natural strengths or even competencies. Avoiding these aspects of the job is not an acceptable response. Successful product managers confront these head-on, and realize that they need to get outside their comfort zone for their own sake and for the sake of their product.

If there is an area where your discomfort comes from lack of experience or expertise, then bolstering your knowledge should make you more willing to address those types of issues. For example, if you avoid financial analysis because you are weak in that area, work with someone from finance or another product manager with a quantitative background to improve your knowledge. You do not need to become a finance expert, though they can help you improve at least to the point where your lack of experience does not cause you to avoid that important area of your job.

Good product managers succeed by learning to be comfortable doing things that make them uncomfortable. You do not need to necessarily have to learn to enjoy them — that may be impossible — though you do need to accept that they are necessary. A good product manager will put their own personal comfort level aside and do the right thing for the product and the organization.

Translations available:

• Chinese
• Portuguese