If you want to be a good product manager, speak in the language your customers use. Speaking in the customers’ language means two things: making sure that your language and approach resonates with the market, and making sure that you are tailoring your marketing effectively to the type of buyer/persona.

If you’ve told family members or friends that you work in marketing, you may have received responses of chuckles and eye rolls. Have they followed up with jokes about “paradigm” and “synergy” and “world class”? Their reaction is understandable, given the sheer amount of bad product marketing that is out there in the world. Bad marketing gives marketers a bad name, but good marketing can improve the impression of marketers by increasing overall marketing effectiveness and driving companies’ success and revenues.

Too often websites, brochures, and other marketing materials are filled with jargon that only makes sense to people within the company or to industry insiders. Sure, your whole product development team might know what the acronym means, but does the customer? Does a “scalable, best-of-breed cloud-based framework leveraging cutting-edge XYZ technology” mean anything to your buyer (or even your sales team, for that matter)?

Customers don’t care about features, they care about benefits. They don’t care about whether your solution is “built on the newest JRE platform” or not, so long as it “works on all devices.” Saying that your product “addresses key government regulations” is much clearer — and more concise — than listing a handful of acronyms.

Not only do you need to talk about benefits in language the reader will understand, you also need to think about the target reader(s). For most products — especially those in business-to-business markets — there is not a single individual “customer,” and you need to address those buyer personas differently. With an enterprise IT purchase, for example, the IT manager deciding which product fits the organization’s needs the best is going to have different questions, concerns, and lingo than the finance manager approving the expenditure. In that case, the IT buyer may really want to know about the technical jargon, while the finance buyer may be more concerned about long-term maintenance costs and licensing terms.

When you address the right buyer in their terminology, it allows them to determine better whether the product addresses their needs and allows you to overcome any potential hurdles they may have in the purchase process. There are few things worse than convincing several key stakeholders that you have the right solution for them, only to be hung up on one required approver because your messaging didn’t speak their language.

The most ineffective product marketing is filled with internal jargon, overused hyperbole, and targets the wrong audience. The best product marketing connects with the customer by speaking in terms which they understand and which resonate with their needs.

By understanding the language your buyers use, and understanding the differences between your different buyer personas, you’ll not only make your marketing much more effective, but your company revenues may grow dramatically. Plus, as a side benefit, you just may change the reaction you get from family and friends.

Note: A version of this was originally published in 42 Rules for Product Marketing, along with 41 other rules contributed by leading product marketing experts.

If you want to be a good product manager, satisfy customers first before attempting to delight them. There is a lot of talk lately about how to “delight the customer,” and organizations are attempting to do this through exceptional customer service or unexpected product features. This likely driven by an attempt to generate buzz and goodwill by customers raving about these delights, often on social media. When done well and appropriately, the benefits of these delighting product aspects can truly differentiate an offering and an organization.

However, when companies attempt to add delights to a product or service without first satisfying the basic needs and expectations of customers, the extra add-ons have the opposite effect. When customers see a company putting effort into neat/cool/unnecessary features or benefits but ignoring basic fundamental aspects, it implies that the organization is either (a) trying to cover up their faults, or (b) oblivious to customer needs. Either way, it does not send a positive message to the market and is likely to backfire.

Simply put, you can not exceed the customer’s expectations without first meeting them. Furthermore, to paraphrase Dan Pallotta (from his excellent blog post I Don’t Understand What Anyone Is Saying Anymore), it is so rare that a customer actually has their expectations met, much less exceeded — a problem caused by companies not having any idea of what the customer’s expectations are in the first place, or forgetting basic tenants of customer service. This lack of customer understanding can have disastrous results.

Take the example of Qantas Airlines, which launched a contest on Twitter which asked customers to respond with their “dream luxury inflight experience.” Normally, this would have been a reasonable promotion, but, as David Meerman Scott writes in his blog post Qantas Airways Twitter #fail:

In the past month, Qantas had faced a major strike, which grounded the fleet and has experienced ongoing disputes with the unions that represent pilots, mechanics, baggage handlers, and caterers.

The travelling public was greatly inconvenienced during this period of turmoil and cancelled flights. I had friends who couldn’t make it to America for long-planned meetings because of the strike.

Qantas offering this frivolous contest struck people as insensitive.

Luckily, there are other companies and products more successful at delighting customers, but only because they have first satisfied basic needs. For example:

• The Volkswagen Beetle — both the original 1950s version, and the “new” 1998 revision — famously included a flower vase on the dashboard. A bud vase in a car is certainly an unnecessary feature, though one which captured a lot of attention from customers. Luckily for VW, the reaction was positive because the car met all the expectations of potential buyers and then some. Had the car suffered from poor reliability, dismal fuel economy, safety problems, or any other major flaws, the bud vase strategy would have backfired. (Sidenote: VW announced earlier in 2011 that the next version of the classic car would not include a bud vase, in an attempt to make it seem less like a “chick car.”)
• MailChimp is an email marketing service provider, competing in a growing and fairly crowded market. They stand out from their competitors through their quirky and comical yet friendly style. A newsletter administrator is notified of a new subscriber to their mailing list not through a dry, curt note, but with a friendly “Nice! Guess people like what you’re saying.” Analytics showing which countries are most popular are noted by “Hey look at you being all popular in these countries!” Newsletter unsubscribes are announced with “Nuts, you had a few people jump ship. Ah, who needs them anyway?” This style is beyond just the copywriting (though their recently-unearthed internal style guide — Voice and Tone — provides many more examples), but it permeates their entire company culture. Of course, this is only successful because the fundamental service that MailChimp covers the needs of customers and is on par with others in the market. Had they attempted this style but offered a product which was missing several expected features, customers would likely jump ship to another less quirky but more reliable competitor.
• Google’s “Easter Eggs” are uncovered on a fairly regular basis, from the recent let it snow (which displays falling snow) and Happy Hanukkah (which adds a Star of David banner below the search box) to the more obscure do a barrel roll. The decorative changes to their homepage logo — known as Doodle 4 Google — have taken on a life of their own, to the point where there is a team of Doodlers dedicated to these regular logo changes. Clearly, these Doodles and easter eggs are successful in getting users to return over and over again to the site, but only because they are (at a minimum) satisfied with the quality of the search results they receive. A less-robust search engine which attempts these attention-grabbing tricks would certainly have not have as positive a response from the market.

As a product manager, when a opportunity to “delight” the customer appears, but before acting on it immediately, ask yourself these questions:

• Has the product first satsfied the basic customer needs?
• Are there any obvious flaws in the product which should first be addressed?
• Does the effort needed to “delight” the customer have the potential to offer a return?
• Is it likely that a customer will notice this “delighting” aspect?
• Is this “delight” done in a way to enhance the current offering, or will it have the potential to highlight preexisting issues?

It is a noble goal to delight the customer, as both companies and consumers benefit when executed well. However, product managers need to ensure that basic needs and fundamental expectations are first addressed before attempting to enhance products and services with unexpected delights.

If you want to be a good product manager, take the blame for problems with your product. Blaming others is never productive — it ruins relationships, decreases morale, makes others less likely to help in the future, and, most importantly, does not do anything to correct any problems which might exist.

Product managers may complain about having all of the responsibility and none of the authority and may argue that blame is an appropriate response when something goes wrong and it is outside of their control. Unfortunately, this is destructive behavior which may provide a temporary reprieve but will inevitably make the problem worse.

Blaming others is dangerous not just because it is counterproductive, but also because it delays — and likely amplifies — the fallout related to the problem. For example, maybe a product is not selling well, and you blame the salespeople, whom you claim are just not good at their job. In reality, the problem may be that the salespeople were not trained appropriately on it, or that they do not have enough support from sales engineers, or that they do not have high quality leads on which to follow up. There could be a whole myriad of reasons why the product is not selling beyond just the skills and ability of the sales team.

Blaming the salespeople in this example does not fix the problem. Replacing the salespeople does not fix the problem either — a different sales group would likely have similar (lack of) results if the underlying and related issues are not addressed. Imagine that you blame sales and succeed in getting a replacement sales team, but do not address the root causes of the slow sales. If that new sales team is not successful, you not only have alienated a large group of people within (and now outside of) your organization, but you have put your credibility and career in serious jeopardy.

Ultimately, even if your problems are the result of another person or group, it still does no good to blame them. In fact, it is usually counterproductive. You will need their help to fix the problem, and blaming them means they will feel more insecure and will be more likely to put energy into defending themselves rather than improving what is wrong.

So why do product managers blame others? There are probably a myriad of reasons, though most frequently it is to avoid looking weak. There is a mistaken belief that by deflecting problems on to others, you look infallible. The irony is that most people are smart enough to see through this, and when you attempt to deflect the blame off yourself, people lose respect for you and you end up looking weaker. Accepting responsibility is a sign of a strong leader — one for whom a single problem is not going to cause a downfall.

There are certainly times when others make mistakes and they need to be held responsible. A good product manager does not let obvious or intentional mistakes go unnoticed; a good product manager addresses them professionally and works towards a solution. More importantly, a good product manager seeks to get to the root of the problem and address it so that the problem goes away; even better, a good product manager learns from the issue and institutionalizes a solution so similar problems do not come up again.

Take the earlier examples: If customers are complaining about bugs, is that a QA problem? It could be that QA was understaffed, or that they were pressured to push the release out the door before they felt it was ready. It could be that the engineers did not do adequate initial testing before handing off to QA. It could be because the developers did not get clear and complete specifications, so they made decisions about how the product should function; absent of proper direction, this results in an classic example of “It’s not a bug, it’s a feature.” It could be (and often is) that a combination of various forces which, when combined, created the problem of a buggy product being sold to customers.

Rather than finger-pointing, product managers need to step up and accept the blame when a product is having problems. By definition, they manage the product, and with that position and title comes the responsibility to own the success of the product. Do not sweep problems under the rug or blame others — acknowledge the issues and take the lead in fixing them. The product development team and other internal stakeholders will respect you more for taking ownership and not “throwing them under the bus,” making those groups and individuals more likely to put in the extra effort to lend a hand this time and in the future. Then, when you address the issues and things start to get on track, share the credit, and you will end up being not just a successful product manager but a well-regarded product leader.

If you want to be a good product manager, be comfortable getting involved in all aspects of your product. Ignoring issues which demand further scrutiny is a sure-fire way to miss important details, hurt your credibility among the product development team and other internal stakeholders, and reduce your overall effectiveness as a product manager.

Product managers should know how to and spend time with activities like:

• Follow up with a customer after a salesperson reports a customer complaint during a sales call
• Getting to the root cause of strange problems being reported by customer support
• Working out details of the implications of product plans with internal groups like finance, legal, and sales operations
• Conducting customer interviews personally (as opposed to delegating this to other internal or external resources)

Often product managers do not get involved in these activities because either they do not know how to do them, are not comfortable doing them, believe that their other duties are more important, or feel though they are “above” doing some of these activities.

This is not to say that a product manager should be involved in all of the “none of the above” tasks at all times. Often, product managers fail because they are perceived as the person who should do all of the miscellaneous work, or they spend too much time in tactical responsibilities rather than delegating those. However, product managers should get involved in some details from time to time for a number of reasons:

1. It will help you identify things related to the product which you would not find out if someone else carried out the task. Yes, a customer service representative can follow up with a major customer to find out more details about the error they received, and they will do a good job of it — but they may only be focused on identifying more out about the error and when it occurred. If you follow up, you will (should) also probe more to learn the scenario which led to the customer performing the task which caused the error, how often that customer performs that task, the broader scenario surrounding that task, the value your product provides by solving the customer need need, and a long list of other information which you would not have learned by delegating the follow-up to someone else.
2. It will give you credibility with your colleagues. There is nothing which turns off colleagues more than responding to a request they feel is completely reasonable with a response that you do not have time for their request, that their request is not important, or that the request is “not my job.” Implying that you are “too good” to do something (but your colleague is not) is a recipe for disaster for product managers, whose success depends on influincing people over whom they do not have authority. When you can go the extra mile and help them out with a problem, show them that their request is important, act courtesly and respectfully, and finish what you started in a timely fashion, your colleague will be more than willing to return the favor at some point in the future. (Bonus points if you genuinely thank them for the opportunity to get involved and for their assistance along the way.)
3. It will help make you a better product manager by teaching you about other areas of the business. By “rolling up your sleeves” and diving into different areas within your organization, you will make yourself more knowledgeable about the overall operations of your company and about the various aspects of business in general. The more you learn about the manufacturing operations, the supply chain, the CRM system, or the human resources policies (yes, even HR), the more well-rounded you will become, making you a more valuable product manager for your organization and a more marketable product manager overall.

Finding the right balance is important — too much time spent in the details will take time and attention away from important strategic responsibilities, though avoiding all of the details will shield you from important information which can help enlighten your strategic responsibilities. Product managers who are comfortable getting involved in all aspects of their product and can devote the right amount of time to these details will undoubtedly be more valuable and successful product managers in the long run.

If you want to be a good product manager,plan, protect, and position yourself for future competition. If you are entering a market where there are competitors today, it is fairly certain that there will be new competitors tomorrow. If you have found something “new to the world,” it is guaranteed that others will follow you in to the market if you are successful. As a product manager, you need to plan for future competition, protect yourself from it, and position yourself to actually use that future competition to your advantage.

There have been a number of examples recently showing how new competitors — and in many cases competitors who are much larger and more powerful — have entered certain markets, and how existing products have been prepared and responded effectively.

Apple’s iCloud service is currently the buzz of the technology industry. Only time will tell about  the impact of Apple’s iCloud service, but the announcement alone created a lot of questions around its impact on existing services (for example, the Fortune story “Why iCloud won’t send the competition to the ground“).

Dropbox used the announcement as an opportunity to showcase the additional problems they already solve today that iCloud will not address. They likely predicted market entry by Apple (and Google, and Amazon, and others) and designed their solution accordingly. By supporting additional use cases — including the need to access files on multiple platforms and the need to share files with others — Dropbox has a good chance of emerging from the iCloud release not just unscathed but potentially stronger, as Apple’s entry brings more interest and attention into the benefits of cloud-based computing.

In another technology example, the popular screen capture tool Snagit identified a need for a simple and easy screen capture tool and built a large customer base around their well-designed solution. However, Windows 7 included a built-in Snipping Tool providing the same functionality.

Is Snagit doomed? Unlikely. First, they long ago began adding additional functionality to address more complex needs and problems around screen capture — including more complex post-capture editing features, add-in toolbars for common software programs, and a wider variety of different screen capturing options. While Windows may meet the needs of some users, for the market segments on which Snagit focuses — including technology professionals, trainers, and graphic designers — the built-in functionality Windows offers will be too limited, and Snagit will be able to retain their customer base. And by introducing a whole new segment of the market to screen capturing for the first time, Microsoft has expanded the potential market for Snagit, since likely some users discovering screen capturing through the Snipping Tool for the first time will feel limited and look for a more robust solution.

Secondly, TechSmith, the company that makes Snagit, did not rest on their laurels and stop at static screen capture. Years ago they innovated and expanded their product suite to related offerings, including video capture (Camtasia), usability testing and market research software (Morae), and online screen and video sharing (Screencast). Had TechSmith simply added incremental enhancements based on current customer feedback, they would be left simply with a bloated Snagit tool and in a much more vulnerable position with the release of Microsoft’s Snipping Tool.

Protecting against future competition does not always mean product innovation, however. For example, with a rather simple consumer product like bleach, preparing yourself for future competition may focus on marketing and distribution. When Proctor & Gamble tried to take on leader Clorox in the bleach market, they found that Clorox was prepared for this potential competition and reacted swiftly, according to this interview with former P&G’s former CEO A.G. Lafley:

P&G chose Portland, Maine, as the test market, hoping to escape notice from Clorox, which was headquartered in Oakland, California. But Clorox got wind of the plan in time to distribute free gallons of Clorox bleach to every household in Portland, making all P&G’s advertising dollars, sampling, and couponing irrelevant. “Game, set, match to Clorox,” Lafley says.

Had Clorox been unprepared or unable to react swiftly, they may have faced more severe competitive threats with P&G attempting to enter the market. True, it could be argued that Clorox had made themselves vulnerable to competition by not being more innovative with their core product. However, they were effectively able to put down the competitive threat and are still the market leader in traditional bleach, while both Clorox and P&G have gone on to innovate tremendously in other areas.

Hoping you do not face competition or planning on riding out the good times until a larger competitor eventually enters the market are not effective strategies. It is possible to effectively fend off competitors — be they scrappy startups or well-funded multinationals — though this can only done through proper planning, preparation, and proactive innovation. Good product managers will consider traditional and possible new competitors in their overall strategic planning and roadmapping, and guide their products accordingly.

If you want to be a good product manager, understand your customers’ buying process and factor that in to the overall design of your product. Yes, you must have a good product in order to succeed, but a good product alone will not lead to sales success. Without understanding the process which your customers go through to evaluate and buy a product, you may be missing crucial elements in the product or in surrounding elements — everything from sales channels to product support — which will impact potential revenue.

• What budget is used to fund purchase of the product? Understanding where the money comes from within an organization is important because the budget for that area may be shrinking. For example, you may develop a fantastic service to help companies organize and optimize their in-person training, but if budgets for in-person training is being cut across the board, you’ll be facing an uphill battle no matter how good your offering is.
• Whose approval is needed for the purchase? Depending on the type of product, and the amount that the product will cost, there may be other individuals who need to approve the purchase. For companies, it is standard that a manager has a certain level of signing authority, above which the individual will need to seek his or her manager’s approval. You may have designed a product which will improve the effectiveness of a company’s marketing efforts, but the price point may be such that it requires approval by higher levels of management. Those higher levels of management may have different priorities, questions, and timelines for approving such a purchase, so understanding those approval levels and their implication is essential to build your overall value proposition.
• Does the purchaser have a different set of criteria than the user? Products for children are classic examples of this. Toddlers never purchase their own toys — and the purchasers (most likely parents or relatives) will have different criteria than their young users. Parents may look for criteria like durability, materials used, age appropriateness, and even country of manufacture; children may focus more on colors, shape, familiar characters, or unintended uses. (One can imagine an inner monologue of “I like this toy car because it’s black and it would let me pretend that I’m talking on a cell phone just like daddy.”) Purchase criteria need to be factored into the design, development, and marketing of a product to ensure that all elements of the product strategy align with the factors which will influence purchase.
• Are the purchasers used to making this type of a purchase? Addressing an unmet need of a customer segment who has been ignored is a ripe opportunity for product success, though it presents new challenges in executing a sale of a type which may have no precedent. Maybe you have software that will help a company with their financial reporting obligations. The users of this software and the decision to purchase may come from a Finance Department, which may have no experience evaluating this type of software. Or, you may be selling a product which is a large capital expenditure to a group which is used to deciding on smaller operational expenses, and they may be paralyzed by the prospect of a large initial investment, regardless of its long-term benefits.
• Are there other decision-makers which need to be included? Many companies traditionally have grown by selling the same products to more of the same customers, and also selling new “similar” products to those same customers as well. As products branch out to new groups within existing customers or entirely new customer groups, there may be new stakeholders for which there needs to be accounting. Imagine you are a product manager at a software company which traditionally has provided products to allow individuals with an organization to perform statistical analysis. If you now plan on launching an product to facilitate enterprise data mining of customer information, there may be a whole new set of individuals involved in the purchase process — those focusing on legal, security, and privacy — whom were never a part of the purchase decision for your other products.

There are a multitude of different factors which need to be accounted for when creating a product and setting it up for success. Identifying unmet market needs and meeting them is a crucial part of successful product management, but if the overall purchase process is not understood and accounted for, all of the great work which went in to developing an innovative product will be all for naught.

If you want to be a good product manager, understand relevant switching costs and attempt to reduce them as much as possible to improve customer acquisition and perceived value. Every product has a cost, whether implicit or explicit. Even “free” products have a cost, most notably the time a consumer spends learning and using it. People will buy and use products where the value and benefit they get from the product is higher than the cost to them.

Want even more product management tips? Follow me on Twitter for daily bite-sized nuggets on product management and innovation.

In most cases, the main cost is explicit — the price of the product to purchase. However, in many cases, the cost to someone is beyond just what they have to spend and takes into account other factors. These switching costs take multiple different forms:

• Learning cost: A new product might have improved functionality or capability which requires an investment of time and training to take advantage of. Switching from a car automatic to manual transmission may require the driver to learn how to drive a stick-shift. Switching from Windows to OS X may offer some benefits, though there is initially some loss of efficiency at a minimum for even the most experienced computer users. For a computer programmer, coding in a new programming language may offer many benefits, though it will require time to learn the language and potentially cost to purchase resources and training in order to become knowledgeable about the new language.
• Opportunity cost: In some cases, consumers have to deal with mutually exclusive product offerings, and choosing a new one which provides benefits may require losing some benefits their current offering provides. A hospital choosing an electronic medical record system on which to standardize will select the option which best meets their needs, though invariably there will be features and benefits of other systems of which they will miss out. A long-time elite member of one airline’s frequent flyer program considering a switch to another airline as their primary carrier will invariably get some additional benefits with the new program, though will likely have to give up perks of their previous program.
• Implementation cost: The cost of getting to the point where a product can be actually used is often higher than the cost of the product itself and is often a huge consideration in enterprise environments. Installing a new ecommerce system may offer significant improvements for an online retailer, though there will likely be costs in adapting that system to billing, fulfillment, customer service, and related technologies within the organization. Solar roof panels may be an improved option for a homeowner looking to reduce energy costs, but there are significant costs in not only installing the panels themselves but wiring the home’s electrical system to take advantage of the new technology.
• Conversion cost: For some products, data or settings need to be converted from the old to the new product. Switching to a new contact management system involves proper transition of the data from the old to new application to ensure no data is lost or rearranged. Anyone who has avoided upgrading an aging computer knows the cost (in time, and often in money) to convert data and settings to the new version.

Decisions to stick with a current (and often inferior) product rather than switch or upgrade can also be attributed to these more psychological or behavioral reasons:

• Inertia: People in general stick with what makes them comfortable. They use products that have worked well for them, and do things a certain way because they have always done things a certain way. (“My mother always used this brand of pasta sauce, and her mother always used this brand of pasta sauce…”)
• Fear of change: Rather than looking at the benefits of a change, people may look at only the things which can go wrong. (“What if the new detergent doesn’t clean as well as the old one? What if my cell phone number doesn’t get switched properly to my new carrier and I’m without a phone for several days?”)
• Overestimation of the difficulty of the change: Some changes can seem more daunting than they actually are. If consumers do not have a clear picture of what the change requires, they may resist. (“I’d like to switch to a new bank account with higher interest rates, though I can’t bear to think of the hassle of changing my direct deposit setup and automatic bill payments.”)

Switching costs are relevant for most products in some form. Even with totally new and groundbreaking products, consumers are switching from some other prior option, even if not a direct competitor. (Consumers using ZipCar for the first time, for example, do not switch from using Hertz or Avis, but instead from using public transportation, a taxi, or maybe borrowing a friend’s car.) Product managers need to identify what the potential barriers to adopting their product could be and how to overcome these obstacles. These can be built in to the product or service itself to not only remove objections but actually provide additional competitive differentiators. For example:

• A customer relationship management (CRM) application provider could offer data setup for free to all customers who sign up for an initial contract term to ensure that conversion costs are not a barrier to adoption. To provide additional benefit, they could offer to “clean” the data while converting it, providing an additional service and benefit to customers.
• For a product with a learning curve, certain elements like an online demo and customer testimonials on the product’s ease of use could address customer fears about learning cost. Discussion forums, free online training, and implementation guides could help support users after adoption as well.
• A bank attempting to lure customers to a new checking account offering could offer a checklist of automatic payments the customer needs to consider changing. Better yet, the bank could offer contact information for the most common payees, forms for the customer to provide to their payroll department to change direct deposit settings, or even provide personal assistance in setting up automatic bill payments on the new account.

Successful product management is not just about having a “better” product — it is about understanding what it will take for a customer to adopt the product. By understanding the explicit and implicit reasons for a customer to resist switching, product managers can better design their offerings to allow a larger number of people to actually adopt them.

Want even more product management tips? Follow me on Twitter for daily bite-sized nuggets on product management and innovation.

If you want to be a good product manager, realize that your product is likely one of a multitude which your customers use in the course of a day. Only in very unique cases is a product truly the center of someone’s universe.  Product development teams need to recognize that they are thinking about their product much more than anyone else outside their organization, and make decisions about design and communication accordingly.

Overestimating the importance and focus your customers place on your product can have negative implications — here are a few examples:

• You come up with a fancy new user interface, which you think is “better” than anything else out there, though it’s so different than the other programs your customers interact with that they can’t figure out how to use it.
• You add features that users would find relevant only if they used your product exclusively.
• You do not consider any potential opportunities to integrate your product with other services or products, and thus do not realize that those integration touchpoints are key to users’ workflows.
• You use very specific terminology which is not easily recognized by anyone new to your product.
• You send emails to people on your mailing list talking about nuances of your product, yet you don’t remind recipients what your product actually is. (I received an email like this recently, with the email boasting about new features in their 2.0 version — yet nothing in the email told me what the product was or what it did. Had I been a regular user, I would not have needed this explanation; however, since this was one of probably many  web-based free “beta” products I had signed up for in the past year, I couldn’t remember what it was or why I would have tried it.)

As a product manager, you likely think about your product all day, every day. It is very unlikely that your customers think about or use your product nearly that much; to them, it is more likely just one of a thousand stars in the galaxy.

Taking this into account, here are a few things a product manager can do:

• Use existing standards whenever they are relevant and applicable. “Control-C” is the shortcut for copy — do not use that key combination for some other function. If there are standard sizes, connections, conventions, or metaphors with which customers are familiar, avoid breaking them unless are absolutely necessary — and even then weigh the benefits of the new approach versus the drawbacks of doing something different than what is expected.
• Reinforce your positioning and benefits on a regular basis. For customers who are using a multitude of products, they may need a reminder about the explicit benefits and value proposition even well after they have made a purchase decision. Confusion or forgetting about your product could lead to apathy, lack of recommendations / referrals, or even negative attention.
• Understand how your product functions as part of a system. Realize that your product needs to work with other products which your organization produces as well as products and systems created by others — including your competitors.

By not overestimating the importance and use of your product in your customer base, you will end up creating an improved product which ultimately will better serve the needs of your customers — and, in a strange coincidence, may actually make it a more important part of their day.

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.