Some Product Management reading

Over the last few years I’ve written several articles that have been published by the folks at

I discussed one such article, Product Management Axioms, in another blog post.

The remaining articles cover different topics related to product management, from beta programs to prioritizing customer feedback to a discussion on how many product managers are really enough in an organization.

I’d love to hear your feedback on any of them.

Building a Better Beta
Detailed description of the key elements of beta programs and ways to make them effective across teams in a software company

A Model for Metrics Driven Feature Prioritization
Describes a method for including large numbers of customers in a closed-loop dialog on product direction

You Can Never Have Too Many Product Managers
Defining the value of Product Management in a software company is difficult but critical. Companies must ensure the Product Management role does not bottleneck other parts of the company.

A House with no Front Door
Creating great software products requires diligence and forethought. Efforts that put development efficiencies ahead of user needs simply increase complexity and cost for the vendor over time.


SWOT Analysis

Every product manager has to do a SWOT analysis at some point in his or her career. The only trouble is that they’re often so few and far between that no one ever really gets very good at doing them. This is generally not a big deal, as a SWOT analysis is pretty easy to do, but doing a few simple things will make your SWOT documents a lot more effective.



First, on the SWOT elements: strengths and weaknesses should reflect internal characteristics. Opportunities and threats are external or environmental.

So, for example, a lack of customers is not a weakness, unless there are no customers buying any product like yours. “Lack of market” is a threat, “lack of market penetration” is a weakness. Try to focus on issues that are clearly internal or external in origin. Choosing “it’s nobody’s fault” types of issues doesn’t make for a compelling SWOT.

Once you have identified a few clear issues in each category you can begin the really important part of the SWOT analysis. Early in my career I just made a list in each category and left it at that. No conclusions, no recommendations. Not surprisingly, I didn’t see SWOT as having a lot of value. After doing numerous SWOT analyses in school I started to see the value of a more thorough job.

The real value comes when you make a matrix and compare your strengths and weaknesses against opportunities and threats:


So see how you can use your strengths to exploit opportunities and offset strengths. Look for areas to avoid by seeing where threats attack your weaknesses and see where you need to improve weaknesses to take advantage of opportunities.

It’s this second level of analysis that really brings out useful recommendations and an action plan from SWOT analysis.

How to be a GREAT Product Manager (Boxed Set with Bonus Features!)

I recently completed a six part series of articles entitled:

How to be a GREAT Product Manager

I started writing the series as an analogue to Ken Norton’s posting on his blog: How to hire a product manager.

Ken lays out six major points on how to hire a PM. Each part of my series focused on the flip side of his points and focused on how to be a great PM. The following table shows the two side by side:

Hiring a great PM

Being a great PM

1 Hire all the smart people Don’t just sound smart, act smart and be smart
2 Have a strong technical background Be technical without becoming a technologist
3 “Spidey-sense” product instincts and creativity “Spidey-sense” instincts are good, hard data is way better
4 Leadership that’s earned Follow the 4 Cs of Leadership
5 Ability to channel multiple points of view Be an integrator, translator and communicator
6 Give me someone who’s shipped something Own the product from conception to completion and beyond

There’s probably a lot more to write on both hiring and being a great product manager. When hiring you only have a limited amount of time to assess the person, ask key questions, see some of their previous work if possible, check references etc.

Most of the time, the hiring decision comes down to a mix of the person’s performance in the interviews and a gut call made by the hiring manager. Some people interview well but perform poorly. Others don’t interview as well but deliver results. Finding good talent is always tough, and this is especially true in the case of PMs.

Being a great product manager is not easy either. Aside from rising to the challenge on your own, there can be organizational, political or business hurdles hindering your path to success. The role of a product manager in a larger company is likely very different from the same role in a startup.

It can be very hard to make a big imprint in a larger company where strategy and major product direction decisions are oft-times made at the senior management level, with product managers being tasked to execute on those decisions. In a startup, I’ll bet you’re likely understaffed with more to do than time to do it.

In either case, you can still rise above the noise and be effective. Focus on the key objectives you need to deliver and ensure those get done in a timely manner. Don’t be a “just-in-time” product manager. It leaves you no wiggle room if you meet unexpected delays and makes people depending on your rather nervous.

Beyond the key objectives, keep watch for places where you can help improve how the organizations builds, markets, sells and supports your products. If you notice that the evaluation process for your software is cumbersome and this is impacting sales, help identify and define the solution.

If you see that sales consultants aren’t adequately trained then work to get them the help they need. If you notice that customers are getting frustrated with the quality of support (despite what the results of the 3rd party customer satisfaction survey says), raise it with Support management or other executives. The point here is that beyond the product(s) you manage, identify ways to make the company better and be part of the solution team.

Be wary of internal power structures and political circles. It is far too easy to get encumbered by company politics or suppressed by hostile power structures. This is more often the case in larger companies, particularly those who’ve grown quickly and where many of the original or early employees have risen to management positions.

Dealing with and navigating internal power structures could be the subject of a series of blog postings (hmmmm), but all I will say for now is tread carefully and knowingly when in enemy territory.

In the end, there is no magic recipe to ensure you are a successful product manager. It takes a lot of effort, insight and thinking. But if you keep those 6 rules in mind and try to apply them wherever possible, you’ll certainly increase your chances of success.


How to be a GREAT Product Manager (part 6)

Own the product from conception to completion and beyond

In my early product management jobs, I focused a lot on the process of product management. A CEO of a startup I worked for told me that my approach to product management was “very academic” in nature. He viewed himself as a “get it done by any means necessary” entrepreneur, while I viewed myself as a”get it done right” product manager.

The startup was a very sales/deal driven company, as many startups tend to be. Putting product management in place in such an organization is not easy. But having a process focus is very important for a product manager. Every other function, from sales to marketing to development to finance to HR implement processes.

But because product managers work across these functional units, people don’t realize or understand that even in small companies there must be a repeatable and scalable process to conceive, research, define, develop, test, launch, promote, sell, support and sustain winning products! 🙂

And while product managers have a direct responsibility in some of these 10 areas and indirect responsibility in others, PMs absolutely have a core responsibility to oversee and align the activities of other teams across this entire process. I’m not talking about managing those people directly or telling them what they should do. I’m assuming people know how to do their respective jobs. What I am saying is that if you want to be a great Product Manager, take ownership (not necessarily full control) over the process and lead the teams in alignment through it.

Get alignment from the very beginning
From the start, as you (and/or your PM team) are doing your research, clearly define the context and vocabulary necessary to effectively convey the research results to the intended audiences. This vocabulary, whether related to personae/roles, business functions, consumer needs, product architecture or functionality or something else, will become key to bringing everyone into the same frame of reference. This is important because it helps to minimize misinterpretations and miscommunication during the product development and launch process. If people aren’t aligned early on in the process, you are likely to see confusion or conflict later on as requirements are implemented incorrectly or with unacceptable constraints.

As an example, before becoming a product manager, I worked at a company that was developing a fairly sophisticated reporting and visualization framework for business and financial data. One of the engineers was tasked with the requirement to create a flexible means to allow users to format and display numeric and character text (including time, date and multiple international currency values) dynamically for display in pop-up boxes when on-screen entities were moused-over. Are you with me?

He went off, did some research and without a lot of internal discussion, implemented functionality to address the requirement. I was responsible for documenting the functionality. When I saw what he had developed, I was stunned. He had created a flexible — but incredibly complicated — formatting subsystem. Yes, it could do everything and more relative to the requirement, but I’m certain only the engineer and a few other technical people could actually use it. The documentation for this functionality took 60 pages (out of a 600 page reference manual). When people in the company saw how complex it was, the functionality was removed from the product.

What went wrong? A number of things including lack of internal communication, lack of oversight, and lack of involvement from the product manager. Where was he during all this? I don’t recall exactly, but I think he was out, working with sales and trying to close some deals. Helping sales is good. Don’t get me wrong. But not when it comes at the expense of the product being built.

Get your hands good and dirty
During the development cycle, work to keep other teams such as marketing, product marketing, sales, sales consulting, support, channels, alliances and professional services informed and educated on the development status and product functionality. For smaller consumer products or websites, this may not be a difficult task, but for larger enterprise or data center software, this can be a daunting task.

For a major release of a large product, a development cycle will last 12 months or more. There are many decisions that are made during this cycle that need to be conveyed to downstream teams to ensure they can plan ahead for the impact of the new release.

Don’t stop until adoption is clear
Once the product is released, you need to stay focused on the product. You can’t let up and simply go start gathering requirements for the next release. Stay engaged with early customers, partners and the customer facing teams such as sales and professional services. If early customers are upgrading to the new release from a previous version, track those upgrades and follow up with the customers to see how the upgrade went and what comments they have about the new release.

Join members of the sales team on customer and prospect calls and listen to how they are describing and selling the new release, and what the reaction is from the audiences.

  • Are the salespeople on message?
  • Are the sales consultants adequately trained?
  • Do the demos hit on target?
  • Is the market need that you researched and identified oh so long ago, still as relevant and critical as it was back then?

These questions (as well as others) should be the focus of product managers (and product marketers) after product launch.

All too often, I’ve seen people work on a release, have it launch, and then essentially forget about it as they start focusing on the next release. Big mistake. If sales is struggling to sell the product, as the Product Manager, you need to take the challenge on and work to identify and remove the barriers.

Don’t look at it as someone else’s job because it isn’t. Would a CEO let a struggling VP of Sales flounder for a quarter or two? Absolutely not. As a PM, take your cues from the CEO and within reason, do what a CEO would do. Don’t wait for others to tell you what needs to be done. Take charge of your product, make sure it is built right and then ensure it trounces the competition.


Part 5 – Be an integrator, translator and communicator

Should I get me some of that?

Came across this special deal on an electronics retailer’s web site today. Until they explicitly pointed out the incredible savings I was getting if I purchased the CPU and motherboard together, I thought $79.97 was a pretty good price. With the exception of the green arrow (I put it there), this is an actual screen clip from the retailer’s web site. [click to enlarge]


Pointing out that I was saving only $.01 cost them the transaction. Given ecommerce is well over 10 years old, does it make sense that ecommerce sites are still this stupid? Wouldn’t someone managing the site create a requirement that says something like:

If the savings of our bundles are <5% of the combined price of the individual components, do not show actual component prices or the savings.

I like the retailer. They have a reasonably good website, but I’ll have to keep my eyes out for more of these “great deals”.


How does a PM gain insight?

thinker-small.jpgIn a comment on one of Alan’s posts, a reader, Michael, asks, how product managers can gain insight into market and customer needs.

He then lists a number of ways of doing this. I summarize them a bit for brevity.

  1. You could talk directly to customers.
  2. You could talk to a sample of customers (via focus groups or user group meetings or similar).
  3. You could rely on voluntary feedback (like those ghastly product registration cards so many things seem to come with).
  4. You could trawl the web looking for blog entries about your product.
  5. You could solicit feedback from your own sales team.
  6. You could ask your support staff what problems customers keep coming up against
  7. You could talk to industry pundits, who will guess what customers think of your product.
  8. You could ignore the customers and assume that they want what you want.

In another comment, Michael continues:

To pick an example, say you were involved with something like a consumer-grade digital camera (lots on units, lots of customers, scope for plenty of product differentiation). Given the volumes, you can’t talk to all the customers. Given the sales channel, you might not even know who most of the customers are. What can you do for something like this?

For the example above: a consumer-grade digital camera, let’s take a step back and talk about market segmentation. When the camera was being conceived there was an audience in mind for the camera. Today the digital camera market has matured enough that there are clear market segments at which cameras are aimed. For example, a simple segmentation could be:cameras

Now each of these segments defines different types of people, with different budgets, photography experience and photographic intent. When looking to design a camera, you would need to get a clear definition of the segment you’re aiming for, understand the dynamics of that segment (competitors, trends, subsegments etc.) and then start developing the product.

As for gaining insight, once you know the segment and the characteristics of that segment, you know the type of people to talk to: which end users, retailers, distributors etc. Those 8 questions listed earlier (OK, #8 — ignore the customers is probably not a good tactic) are all ways to gain insight, both before, during and after the product is released. Of course, there are many others.

Shifting to software, one of the most well known and oft-cited examples of gaining customer insight was Intuit’s “follow-me -home” program. This program had Intuit staff visit the homes of Quicken users and observe them using the product in their home settings. This program yielded valuable insights into what people did with the product in their home environment and led to several product enhancements such as an electronic paper tape feature in the Quicken calculator.

inside intuit BTW, if you want to read a great book on Intuit’s history and struggles, I recommend Inside Intuit. It covers, what we can now call, the early years, and if I recall [I read the book a long time ago] has a section covering the follow-me-home program.

The follow-me-home program was an example of ethnographic research. Essentially it is fieldwork; getting out into the real world and truly understanding the environment and frames of reference of those who will be using, recommending, selling or distributing your product.

One thing to keep in mind is that when doing fieldwork, it is best to include several people from your organization from teams other than product management. The reason? Because, regardless of how much primary research you do, you will always interpret what you observe and learn through your own personal frame of reference. The patterns you see when conducting the research will likely be somewhat different than the patterns others see. And the conclusions you draw may be different than the conclusions others draw.

Include members of engineering, market and even sales if possible and feasible in your research. Also take other product managers along. At minimum, you’ll have a control element in your sample of interpreters of the data you collect.

I honestly believe it takes a very skilled person to do ethnographic research well. You have to be able to put your personal biases and views aside, and not only listen to what others are saying and doing, but also ask the right questions (open ended, neutral questions) to solicit the input that is needed.

I’ll probably write about this more in future post, but one thing I see lacking in virtually all product management training is any coverage of the skills needed to do good field research. It is such a critical part of the product manager’s job, but I’ve yet to see that topic covered with any level of substance in any training courses aimed at product managers.

The question: “How does a PM gain insight?” is a good one. The answer, quite simply, is that there is no simple answer. Like most things, it takes ongoing effort, communication, thought and dedication.


Waiter: SE, Salesperson, or Product Manager?

Often when I am eating out, I ask the waiter for a recommendation. And so often the response is the same: the waiter responds by telling me what she prefers. Frankly, I don’t care what my waiter prefers! In fact, when I imagine my waiter eating, it reduces my own appetite.

I am really asking (i) what this restaurant specializes in, (ii) what is the most successful or interesting dish to most other customers, and (iii) what dish might fit best with my “goals” for this meal.

The waiter is in such a perfect position to help. She has contact with more eaters than anyone in the restaurant! If she is paying attention, she should have a good sense for what dishes are left unfinished and which ones receive rave reviews. She could respond with “what kind of meal are you in the mood for?”, or, “are you really hungry or looking for something rather light?” With that information in mind, she could recommend something that matches what I’m after and is most popular among her other customers.

Relevant to product management? I think it is:

  • are your sales people inquiring about customer goals before they send the quote or set up the demo?
  • do your sales people understand the typical goals of their prospects? Can they match prospect goals with individual capabilities of your product?
  • when you are talking with people from development, marketing, sales, operations, finance, etc., do they see you as the person who speaks for the customer, or just another person with an opinion?

As the product manager, you need to be the person who speaks to the most customers and prospects in open-ended conversations, and you should also have the broader data based on closed-ended questions.

Please don’t be like my waiter. Gather the data and share it with marketing, development, and sales. This is the best way to garner respect and cultivate your position as the true leader of your product line.