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.

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
• 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:

• Portuguese

If you want to be a good product manager, plan for now and the likely future. Understanding the long-term implications of decisions is important, though possibilities well into the future should not overshadow more pressing short-term decisions.

Too often, good ideas are rejected because they will not hold true “if” lots of things happen. For example, a good design for a database holding 10,000 records may be overruled because it will not scale to 1 million records — despite the fact that only one in a million potential customers would ever have that many entries. Or, some will insist on expending substantial effort to automate a simple manual process which takes 2 minutes to complete and is performed only on occasion, using the argument that if the process ever occurs more frequently (which would be several years into the future, at best), the automated version will be more efficient.

Planning for too far into the future often happens because people are in search of the “perfect” solution. (Surprise — there is never one!) A “good enough” solution might perform well for several months or years; unfortunately, those looking for the “perfect” answer will reject what is “good enough” and insist on a solution that is usually more complicated, more complex, and more expensive.

Another danger in planning ahead too much is that the farther into the future you try to look, the more likely you are that your predictions will be wrong. Anything beyond what is known at this moment is speculation. Sure, some areas are easier to predict than others, though in many aspects of product development, predictions may be little more than educated guesses combined with wild optimism.

Speaking of optimism, the reason for long-term thinking is often that product development teams assume wild success and plan accordingly. Yes, it would be great if you get a million sign ups for your social network in the first week. Sure, you hope that your brilliant marketing campaign drives demand for your entire 12-month inventory in 3 months. What if things do not turn out as well? Unfortunately, most of the too-future thinking is intertwined with extreme optimism (or, in some cases, pessimism). Product managers need to be reasonable and rational in their assumptions and expectations. There is a need to balance hope and positive thinking with reality, and too often product managers and product development teams end up on one end of the spectrum or the other.

As 37signals describes in Optimize for now!:

One of the easiest ways to shoot down good ideas, interesting policies, or worthwhile experiments is by injecting the assumption that whatever you’re doing needs to last forever and ever. … The best way to get to the point of needing more is by optimizing for today. Use the strengths of your current situation instead of being so eager to adopt the hassles of tomorrow.

Rather than planning for the far future, product managers need to plan for what is known and what is reasonable to expect for the future. When ideas are rejected because they will not “scale” to unreasonable levels or due to the fact that they will “only” last for a certain reasonable period of time, the product manager needs to remind the product development team to keep the issues in perspective. Clarify requirements and objectives, understand trade-offs, prioritize appropriately, and make smart decisions based on what is logical today and what is most likely in the future.

Translations available:

• Portuguese

If you want to be a good product manager, engage your sales force. If you manage a product which is sold by direct sales representatives, good relationships with the sales organization is important to the success of your product. Most sales groups sell more than one product, so ensuring that your product has enough “mindshare” among the salespeople for them to keep selling it is key.

There are a few key ways to engage your sales force:

• Develop good relationships with salespeople and sales management: At a most basic level, you need to get to know your sales force. A product manager should be developing good relationships with all other internal stakeholders — marketing, engineering, finance — and sales is often forgotten about since they may be spread out across the country or world. Make an effort to learn their names and their territories, their backgrounds and experience. When you do get to see them in person — at sales meetings or trade shows — make sure to spend time getting to know them. You should not be trying to “schmooze” them or convincing them why your product is the best; you should just be interacting with them as you would with any other person or group with whom you work. It may be easier to spend more time with sales management, since they may be involved in more meetings, they may be part of your product council, or you may see them in the office on a more regular basis. Good relationships with sales managers will help create good relationships with salespeople, since the managers often send signals (implicit or explicit) to their sales forces about whether a product manager is one of “the good ones.”
• Nurture the influential salespeople: In any group, there are natural leaders and standouts. For salespeople, these are often those who are consistently successful, though not necessarily the absolute top performer every year. It could be someone who has an exceptional knowledge of the market, or someone who has experience working for a competitor, or someone who has developed a style which has allowed them to be successful in difficult customer situations. These are the salespeople whom others respect and query for advice, and these influential salespeople can be great champions for your product for obvious reasons. If they develop a passion for your product and if you have a productive relationship with them, those positive benefits will be passed on to others. Additionally, they can serve as a great source of information for you, as they will pass on what they are hearing about from other salespeople, as well as from customers, competitors, and the market in general.
• Spend time on sales calls: A good understanding of sales challenges comes from actually observing the sales process. Just like you need to observe customers to understand market needs, you need to observe salespeople to understand what they need to be successful. Spending time on sales calls — pitching to prospective customers or following up with existing customers — can help you understand the challenges your sales force faces. They will appreciate that you are interested in learning more about what they do and giving them some of your valuable time. It also gives you one-on-one time with sales representatives as you prepare for and debriefing from sales calls. Sometimes, the informal discussions while waiting for an appointment or over coffee after a successful sales call are the most beneficial.
• Answer their questions before they are asked: Responding to questions from your salesforce is good; answering questions before they are asked is better. The better you know your salespeople, their customers, the market, and the type of questions that come up, the better job you can do preparing them for success. Giving them the materials to respond to customer questions quickly makes them look more professional, improves their efficiency, and ensures your customers are receiving consistent information. More importantly, your sales force will be happy, and you’ll have more time to spend developing your strategy and understanding market needs.
• Listen to their input and suggestions: Most salespeople have lots of ideas and suggestions. Though they are not in a product development role, they do hear feedback from customers and come up with potential changes and enhancements based on their own knowledge of the product and the market. Encourage their feedback and express your appreciation for everything they pass along. Though you should not accept suggestions blindly and implement every request that comes your way, product managers should at least give proper consideration to feedback from sales. Even if the ideas never become reality, the fact that you took the time to listen and evaluate the feedback will be appreciated.

This is by no means a complete list of ways to develop a good working relationship with sales, though product managers who follow even just some of these tips will benefit. An effective relationship with sales will help to create a better product that gets the proper attention it deserves from salespeople, ultimately making the product — and the product manager — more successful.

If you want to be a good product manager, ask a good product manager for advice when you need help. So often, product managers get too focused specific tasks and day-to-day duties. They do not take the time to step back from trying to solve specific problems and think about whether they are approaching the issue in the best way.

Think back to a product management challenge you had in the past week. Did you immediately know the best approach? Did you handle the situation perfectly? Were there resources you could have utilized, but didn’t because you were so focused on resolving the issue and moving ahead?

Product managers — and most professionals — often do not utilize resources that can help make their jobs easier and can help improve their effectiveness. Why not?

• Product managers think their problems are unique. They are not. Everyone thinks their product is special or that their situation is different. There are plenty of product managers who have been faced with similar problems and have experience that can be shared.
• Product managers are afraid to share their situation for privacy reasons. This is an understandable concern, though in most cases the perceived risk far outweighs the actual risk. It is possible to describe a problem you are facing at an appropriate level of detail to obtain advice without actually sharing anything proprietary, confidential, or unethical. You will likely find that others have faced similar problems as well, and they will be willing to share their experiences and concerns with you.
• Product managers feel they need to solve the problems themselves. Simply put, most successful people got to where they are because they received help from others. Whether you are a manager or athlete, politician or writer, teacher or doctor, you can become more successful by getting help from others.
• Product managers do not know where to turn for help. Many product managers turn to other product managers within their organization, though this may not provide a wide enough variety of experiences. Other product managers may not have any colleagues internally to provide advice, or may have a limited network of other product managers to consult for advice.

This last point is certainly a challenge for many product managers. The harder it is to ask other product managers for advice, the more one will likely try to solve the problem on his or her own.

There are resources like the Product Strategy Network, PDMA, and AIPMM which can help you find someone to answer your question; Pragmatic Marketing offers you the ability to Ask An Expert; and there are of course plenty of product management blogs which offer tips and techniques.

However, none of these resources make it easy for a product manager to ask a question, get an answer — or multiple answers — from other product managers, and then for that discussion to be captured for other product managers who have the same question. The LinkedIn Answers section on Product Management comes close, though the signal-to-noise ratio makes it difficult to find the good questions and useful answers amidst the plethora of questions irrelevant to most readers.

Ask A Good Product Manager is a new site in the Good Product Manager family. Many readers of this blog send emails asking for advice on product management questions and challenges. Ask A Good Product Manager was created as a way to answer more of these questions and share the answers with other product managers who have the same questions. Good product managers are called on regularly to provide their advice and all readers are encouraged to join in the discussion as well.

Those asking for advice will certainly benefit, as will those asking the questions, since it is well known that teaching and advising others is a great way to improve your own skills. Whether you have a question which you would answered or you have advice to share, hopefully you will contribute at Ask A Good Product Manager and help build another valuable resource for the product management community.

Translations available:

• Portuguese

If you want to be a good product manager, be smart about removing features. Having a lot of features will not make your product great. Great products come from having the right features to solve customer problems, and having those features designed in the right way.

Removing features can and should be done to many products. Good product managers confront this difficult aspect of the job, even though it can be challenging and uncomfortable. Similarly, good product managers do not take this responsibility lightly and only remove features once they understand the implications of any changes to the product and the customer.

The first step to removing features is to not add unnecessary features in the first place. Too often, irrelevant features are added for various reasons — knee jerk response to a customer complaint, an engineer’s pet idea, a lack of understanding of customer needs. Then, when features need to be removed for some reason — technical challenges, support cost, instability — the amount of hassle that a product manager has to endure to minimize impact to customers is much greater than the value than the feature ever provided.

As Marty Cagan of Silicon Valley Product group writes in Great Products by Design:

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.

In a “minimal possible product,” there are no unnecessary features. Every aspect of the product is absolutely essential to meeting the relevant goals.

Unfortunately, product managers often inherit products which were not designed in this way, and there are nearly always features that are not necessary to meeting the business and user objectives.

There are two steps to removing features — identifying which features to remove, and explaining to your customers why you are removing these features.

1. Identifying which features to remove should not be a haphazard progress. Features to remove are those which

• are costly to support
• present a liability to the product
• detract from other value-adding features
• do not fit with the product strategy
• are not used by customers

Once you have identified a feature that falls into this category, identify why the feature was added in the first place. Was it designed to attract to a specific type of customer? Was it relevant when launched yet inappropriate now given technical progress in the years since? Regardless of the validity of the reasoning, first seek to understand it.

Then, see if that reasoning is still valid. It may have made sense given the original product strategy, though now it contradicts the current strategy. Maybe the feature was unique and differentiating at the time and is commonplace and irrelevant now. Perhaps the goal of adding a certain feature was to capture a new type of customer, and that strategy that never succeeded.

Ultimately, product managers should seek to identify any feature whose removal would have no impact on revenue. Yes, customers may complain a bit, though that is likely happening irrespective of whether the feature exists or not. If features can be removed without any measurable loss in customer satisfaction or usage — both of which ultimately lead to revenue — what is the benefit to keeping them? Similarly, if adding a new feature will have no measurable increase in customer satisfaction, usage, or revenue, what is the benefit of adding it? If more product managers kept this in mind as they considered product improvements, they would not get themselves into the situation of having to remove features.

2. Explaining to your customers why you are removing these features is relatively straightforward once you have done the analysis explained above. This is not to imply that you have to deceive your market and put a positive “spin” on the change. You should be honest and straightforward with your customers when describing the reasoning for the change. This should be presented in the terms of the benefits to customers. For example, by removing some icons from the main menu bar, it will make the menu bar easier for new users to learn and quicker for experienced users to use; or, resources will be put towards new features that your customers have been requesting rather than supporting features that are costly to maintain and seldom used.

Make the transition as smooth as possible for customers. Give them plenty of advance notice and make sure to communicate in several forms — for example, through your sales force, via email, postal mail, webinars, etc.

For customers who did rely on the feature which is being removed, you can also suggest alternative options where possible, even when those alternatives are competing products. If the feature really is that unimportant to your users, you will not have droves of customers leaving because of a small change in your product. Customers will appreciate your candor and assistance in minimizing the impacts of the change.

Whenever possible, implement enhancements to your product at the same time that you remove features. Not only does this provide an improved product for your customers, it is a much easier message to communicate. Instead of defending your subtractions, you are extolling your improvements and explaining how those subtractions were a necessary part of the enhancements. 37signals describes this as “every time you add something you take something away,” and the comments and discussion around their blog post show the challenge and confusion around this topic.

Good product managers need to have a clear product strategy and ensure their product remains focused. This can be done by being very regimented in their product development and only adding new features that enhance the product’s value. However, when there are features present whose cost outweighs their value, a product manager must make the difficult decision to remove them to ensure focus on the product’s vision.

Translations available:

• Portuguese

If you want to be a good product manager, put your efforts into promotional campaigns that will impact your key marketing metrics. Though there are plenty of ways to draw attention to your product, good product managers should instead focus on defining the key performance indicators for marketing initiatives and working with the product marketing manager to choose the most appropriate ways to meet those goals. In some cases, that may mean using newer and “innovative” promotional methods; in others, that may mean that more traditional approaches will be best.

Just like other areas within product management, good product managers focus on “what” the marketing campaign needs to accomplish, not “how” to accomplish it. (See Take responsibility for what, not how.) Though it may be tempting to dictate specific marketing tactics, those decisions are best left to the product marketing manager. As a product manager, you should of course be involved in some major decisions, much like you should be involved in major decisions about the design and architecture and technical setup of the product. However, good product managers ensure that overall goals, objectives, and strategy are clear, while the various team members responsible for each area — engineering, marketing, etc. — are given the direction and leeway to make decisions.

Rather than spending time trying to push specific marketing tactics, product managers can be more effective — and help their product marketing managers to be more effective — by focusing on key performance metrics. Ultimately, everything about product management and marketing comes down to limited resources. Product managers and product marketing managers must focus on the most valuable initiatives given the resources available. In order to make a decision about what is most valuable, managers need something to measure against. Are you trying to increase the number of sales or the amount of total revenue? Do you want a large number of warm leads or a small number of hot ones? Would you prefer visitors sign up for our newsletter or contact us for more information? What is your measure of a conversion? What is the goal of a campaign? Only once you answer these questions can you then decide what will best help you meet those goals.

While it may seem desirable to try out new approaches to advertising and promotion, any marketing tactic should be chosen for its benefit relative to its cost, and its overall effectiveness. Good product managers help define marketing goals and work with product marketing managers to determine the best approaches to help meet those goals.

Translations available:

• Portuguese

If you want to be a good product manager, utilize both quantitative and qualitative research for decision making. Numbers are good, though on their own they can not tell the whole story.

Quantitative research is especially useful in product development as a way of confirming findings through qualitative research. For example, you may conduct customer visits or ethnographic research and uncover some unmet needs. You may want to conduct a survey of a wider group of customers to confirm your findings and get more input on specific aspects, such as how important this need is and the cost to the customer of not being able to currently solve this problem.

Many inexperienced product managers have little if any background in any sort of market research techniques. They may rely on the standard techniques — usually surveys and focus groups — whenever research needs to be conducted. Product managers may not even realize that there are other methods available or may not understand why you would use one method over another.

To generalize, qualitative research is usually better for exploring, understanding, and uncovering, while quantitative research is generally better for confirming and clarifying.

If you are trying to discover unmet needs that consumers can not articulate, there is no way that a survey asking respondents to rank items from 1-10 will offer any insight. However, that method would make sense if you have a good idea about priorities for features and you want to get confirmation from a large sample set.

Similarly, if you want to determine whether a market exists for a new product idea and whether consumers would be willing to pay for the product, a single focus group with 6 participants will not provide the information you need. Instead, that would be a useful approach to take if you are trying to understand underlying issues, preferences, and factors that could be helpful in defining a potential solution.

Product managers do not necessarily need to be experts in conducting qualitative and quantitative research, though some experience is certainly useful. More important, however, is that product managers understand the fundamentals of both types of research, their applications and their limitations.

There are many great resources on qualitative research methods; here are two which are recommended:

• Observing the User Experience: A Practitioner’s Guide to User Research by Mike Kuniavsky. This is a fantastic guide to a huge variety of different user research techniques, especially useful for web, software, and technology products. It is sufficiently detailed to be used as a learning guide, while written succinctly enough to be useful for quick reference. (In the interest of fairness, I will note that this book is published by a division of Morgan Kaufmann, which is an imprint of my employer, Elsevier. However, I have no specific organizational or financial connection to this book. I would gladly recommend it even if it was the product of another publisher or if I was not employed by Elsevier.)
• Qualitative Market Research: A Comprehensive Guide by Hy Mariampolski. This provides an excellent overview of different methods along with guidance for those actually conducting the research.

Good product managers will use these and other resources to understand more about the different types of market and user research so that they can utilize the right techniques for the right situation.

Translations available:

• Portuguese

If you want to be a good product manager, find ways around all of the excuses for not visiting customers. There is nothing more valuable that a product manager can do than to spend time understanding a customer’s needs and problems. One hour with a customer will provide more benefit to your product than dozens of hours of meetings at the office.

There will always be reasons not to visit customers, though a good product manager will instead remember the myriad of benefits which come from customer visits. Here are some common roadblocks and how to address them:

• “But I don’t have a budget to visit customers.” It is amazing that an organization would spend well over a hundred thousand dollars on salary, benefits, and overhead for a product manager, plus much more on actually developing products, yet not provide a small fraction of that for undoubtedly the most important part of the product manager’s responsibilities. Product managers who blame lack of funding for not visiting customers are not trying or looking hard enough. The money is there, it just may need to come from other places. Find customers within a short drive — even without requesting reimbursement. Add on an extra day of travel to other trips — to conferences, to other offices for internal meetings, to training — and visit customers in that area. Stay with family and friends to save hotel costs. Visit several customers in one trip, saving on airfare and other travel expenses. Include customer visit expenses in your business cases and requests for project funding.
• “But my customers are too busy to talk with me.” While some customers may legitimately use this as an excuse, most customers would be more than happy for the chance to speak with someone from “headquarters” to provide feedback about the product. Make sure you explain the purpose of your visit and offer the customer something in return, whether that be just the opportunity for them to express their concerns to someone with the power to make changes, or a token of your appreciation that you provide to them for their time. Salespeople often know off the top of their head a handful of customers who would love to provide feedback and are more than willing to give up an hour or even more.
• “But I don’t have any current customers.” It is not just current customers you should be visiting. Former customers, prospective customers, those who purchase competitors’ products — all of these should also be part of your regular research schedule. You should not avoid visits simply because you do not have current customers. In fact, it is probably more important to spend time conducting visits and research if you do not have current customers, as you need to understand why your product is not selling! If your product is not yet released, the more early research and customer understanding you conduct, the better chance you will have to make your product a success.
• “But my sales staff doesn’t want me visiting customers.” It is important for your sales organization to understand the purpose of your visits and support you in this endeavor. Find out the reason for their objections — it could just be a lack of understanding about what you are trying to accomplish. Ride along on some sales calls first to observe the sales process and show them you are interested in learning more about what they do. Use the time between calls or over meals to discuss issues and build rapport with your sales staff. Explain how you conducting a customer visit is different than a sales call, and why both are important. Do not use an initial objection as an excuse to stop trying to visit customers. Instead, use it as the beginning of a conversation. If done correctly, your sales staff will be one of your biggest supporters in arranging visits and will be thrilled when you choose to visit a customer in their territory.

All product managers — good or bad — may face these or other roadblocks to conducting customer visits. What separates the good from the bad is that a good product manager will face these impediments directly and figure out ways around them, while a bad product manager will let these prevent them from conducting customer visits. Remember that the most important responsibility of a product manager is to understand the market, the customers, the unmet needs and the unsolved problems — and that one of the best ways to do that is to conduct customer visits.

Translations available:

• Portuguese

If you want to be a good product manager, investigate problems that exist outside your product. Looking beyond only your product and not having a singular focus simply “managing” your product can be beneficial in several ways:

1. You will find ways to improve your product. Very few products exist on their own. Your product is most likely just one small piece of a myriad of products a customer will interact with in a given day. Products exist in an ecosystem which includes other products created by your company and other companies. A myopic view of the customer needs and usage behavior ignores these other aspects of customers’ lives and activities. These other products could seriously influence how your product is perceived and used, and identifying the connections between these products can help identify problems and opportunities.
2. You will be more focused on customer needs and problems. Product managers expect to be regularly identifying changes and new features, writing requirements, and working to implement them in their products. Unfortunately, this can often lead to adding new functionality because the product manager expects to be busy or has a “quota” of new features to fill, rather than doing the work because it solves an actual problem for the customer. On her Buyer Persona blog, Adele Revella relates a story of a product management supervisor who “tells his product managers that their job is to manage problems, not products. His point is simple – if you give a guy a product to manage, he’ll find capabilities to add to the product, whether the market needs them or not.” She adds:
   

   How many times do product managers argue for investment in a new product capability without thoroughly understanding and communicating the unsolved problem it will address? How much time and money is spent on a go-to-market initiative without first defining the problems that matter most to the buyers, and what attitudes have prevented them from doing business with us?

3. You will find new product opportunities. When new ideas present themselves, rather than trying to fit them in to your current product — or, worse yet, ignore them since they don’t seem relevant — you can see if they have the potential to turn into entirely new products. These could have a higher potential for getting into new markets and creating new revenue streams than just augmenting an existing product.

While it is unlikely that those with the title of “Product Manager” will instead change now to “Problem Manager,” there is considerable merit to the idea of focusing on managing the customer’s problems rather than the product that happens to be currently sold to the customer. A product manager who spends time and effort on identifying the problems customers face — regardless of whether it applies to his/her product or not — will be more likely to identify more unmet needs. These opportunities will ultimately improve the original product, other products the company produces, and also lead to new products that can be developed.

Translations available:

• Portuguese

If you want to be a good product manager, realize that customers will be comparing your product to others. You certainly do not want to focus all of your product development and product marketing efforts on comparing your product to the competition. However, in almost all cases, potential customers will have several options to choose from and you need to address how your product is different (and better).

Depending on your market and how your product is positioned, you may choose to address this issue differently. The choice about whether to specifically mention a competitive product, for example, or how to approach differentiation depends on your position in the market and the attributes of the competition.

Imagine you are creating a portable MP3 player to compete with the iPod. Potential customers will of course be familiar with the iPod and it will likely be their default choice for an MP3 player. It would be pointless to ignore the fact that the iPod exists or assume that your potential customers may not be aware of it. As the dominant product in the market, it is crucial to your success to differentiate your product from the iPod. What are the problems that the iPod does not solve that your product does? What are the unique attributes of your product that will provide value to customers?

It would be a waste of marketing efforts to describe the product (”Plays MP3s! Syncs up with your computer! Has a headphone jack!”) as these are things that customers are already aware of and would expect of the product. Instead, focus on how your product is distinctly different — and hopefully in the customers’ mind better — than the competition (”Plays songs purchased from any online music store! Allows high-quality recording!”). This competitive positioning obviously needs to be present in your product development efforts as well as your marketing and promotion. The differentiating factors must be attributes that are important to the customer, hopefully above and beyond any areas you lag the competition.

Most competitive positioning falls at the extremes. Products either refuse to even acknowledge that there is competition and do not address differentiating factors or they focus all of their energy on going “head to head” directly with their main competition. Successful product development and product marketing is somewhere in the middle. A good product manager will understand the competitive landscape and acknowledge the competition without a single-minded focus on it.

Your customers are not idiots — they know that they have several choices, and your product is just one of the options. Accept that, treat your customers with respect, and clearly articulate the differentiating factors. If you have developed your strategy, done your research, and developed your product appropriately, the benefits will be clear to your customers.

Translations available:

• Portuguese

If you want to be a good product manager, get everyone to agree on goals. Even with just a few different people involved in the creation of a product, there will be divergent views as to what the product should include. Each person will likely have their own “pet” feature that they would like to see included. Their desire may be for a legitimate reason, like a customer support representative lobbying for a change that would reduce unnecessary support calls or a business development manager asking for features to help get certain partner agreements finalized. However, often features are requested for less legitimate reasons, such as a developer wanting to try an implementation of some cool new technology or a marketer demanding a certain feature just because a competitor has it.

It will almost never be possible to include every request in the final product because of time and resource constraints. Even if it was, this would likely cause the product to become overwhelmed with unnecessary features and complexity and lose focus.

Similarly, getting all of your stakeholders to agree on the features is virtually impossible, and even if it was, it would require an unwieldy amount of effort. Product managers — not a committee of dozens — are responsible for defining what goes in to the product. If a product manager is just tallying votes from others, then what value are they adding?

These problems can be avoided by getting agreement around the vision, strategy, and goals for your product. This may be challenging, as stakeholders who are familiar with just submitting feature requests may resist this change. One way to make the transition is for product managers to spend time with others to understand the underlying goals behind their requests.

For example, a salesperson who keeps asking for 802.11g support is not mentioning this because it is her own personal desire to have 802.11g support in the product. Likely, it is because she is getting requests from customers for this technology or potentially has lots sales because it is offered by competitive products. Instead of just adding this feature to the list of future enhancements, use this as an opportunity to clarify the goals — whether they be around market share, revenue, number of customers, type of customers, or even broad areas of functionality. Maybe she is losing out on sales because she is targeting customers that are outside of your core market, and those in the core market do not desire 802.11g support. Maybe your goal for the next year is to improve battery life and adding 802.11g would hurt battery life. Ensuring that you and she and all of your other stakeholders are in agreement on the goals will make it easier for you to make the decision as to whether 802.11g support will best help meet that goal or whether your efforts should be put elsewhere.

An added benefit of focusing on goals rather than features is that it will show your stakeholders that you have a strong command of the product’s direction and that the product is in capable hands. Stakeholders are more likely to strongly demand specific features when they are not confident in the management of the product. Showing that you can manage the product well by defining and aligning the vision and strategy will increase others’ confidence in you and your ability to be a successful product manager, allowing you to spend more time collecting ideas from others than trying to get everyone to agree on them.

Translations available:

• Portuguese

If you want to be a good product manager, sweat the small stuff. Overlooking the details is dangerous for a few reasons:

1. The sum of many small problems may equal a big problem. One defect or idiosyncrasy will not ruin the experience of using a good product, but when you add up enough of those little issues, they can become substantial. A web site with one minor bug is not noticeable. Two bugs that disrupt someone’s experience is annoying but tolerable. As the number of problems grows, the more the person becomes aware of them, and each subsequent issue encountered becomes more and more annoying.
2. That one overlooked detail may be very important. For a web site, a very awkward interface design on your Terms and Conditions page is much less significant than on your Home Page or on your Checkout Confirmation page. Or, for a product where users regularly repeat the same steps, an extra click or scroll or keyboard entry each time may turn from unnoticeable to aggravating in a short period of time.
3. The details may be the differentiator. While you may be convinced that your product is so far ahead of the competition that customers will tolerate flaws, your customers may not agree. Their willingness to put up with defects depends on how important the problem is that your product solves, and how well other products can solve the same problem. Yes, the competition’s product may not meet all of their needs, but at least it does not crash their computer every once in a while. Sure, the other bank’s web site does not have as many nice features, but it is a lot easier to use.

There is a balance that product managers need to find, of course. “No defects” may be cost prohibitive or just technically nearly impossible. Or, it could be that all the bugs and defects could be fixed, but the resources required to do so would then not be able to make other product enhancements that are more important. This is a challenge for product managers — to realize what is “good enough” when it comes to quality and attention to detail, and whether “good enough” really is good enough.

Regardless of how you find that balance, realize that the details do matter. Ignoring them entirely or merely delegating them to others to figure out may not be enough. So many of the products classified under that most exalted banner of “delighting the customer” belong there because of their near perfection in their incredible attention to detail. As Charles Eames said, “The details are not the details. They make the design.”

Translations available:

• Portuguese