A New Definition of Product Management

As a recent thread in a very large product management group on LinkedIn ("So what do you do exactly?") demonstrated (with over 400 responses), we as a community have a bit of difficulty agreeing on what it is we do. We very often hear that PMs are "mini-CEO's". While it's a nice idea and somewhat captures the broad, diverse nature of our responsibility, in my experience, a few direct questions are enough to demonstrate that most product managers are NOT really CEO-like, e.g., "How much budget authority do you have?"

While I understand ours is a nebulous craft, I'm concerned that overstating what we do does little to improve our credibility (and let's face it, in general, credibility is an issue in our profession). At the same time, we have no reason to be coy and understate the critical role many of us play in ensuring the success of our products and thus the company we work for.

After careful consideration, I'll propose a definition, or at least a framework for a definition of product management, that I think is at once accurate (not overstated) yet broad enough to underscore the criticality of product management to successful product development. My definition is based on a simple, intuitive paradigm that was used at one of my previous employers. We often spoke about the people responsible for getting the product "on the shelf" and those responsible for getting it "off the shelf" (and the need for these folks to stay in sync!). The latter referred primarily to marketing, sales and professional services. That left, in effect, product management accountable for getting the product on the shelf. We all know that things are never that well delineated in the life of product managers, and clearly, product managers have a vested interest in making sure a product sells. But, in my career, the lion's share of my time was spent making sure the right product got on the shelf at the right time at a cost that supported our business goals. I was keenly interested in how our product was positioned, how sales were going, with customer support issues etc., but cannot honestly say that I was accountable for these activities. For example, I could try to influence sales planning (and did), but was not at the table when incentives were being defined or sales campaigns were being planned. Other PMs have different experiences, but I've seen very little evidence of broad involvement by product managers in the activities I mentioned (and many others I didn't).

So there your go: My new default response when asked what a product manager does is "We make sure the right product is available to the market at the right time at a cost that supports (business) success."

What do you think? Does my definition reflect your experience?

Next post: Getting Ahead of Tomorrow's Problems: Got Research?

You can find more information on me (including upcoming training dates) at www.prickril.com.

Getting ahead of tomorrow's problems: Got research?

With all the talk about innovation these days in product management circles, I'm consistently surprised that I don't hear much about the role of research in driving product innovation. As a matter of fact, research is overlooked almost completely in the few supposedly comprehensive product management frameworks I've seen. When I say research, I'm primarily referring to research organizations (departments) often found at large, mature companies. 

Those that have worked in smaller companies may not be familiar with bigger shop research organizations. Many medium to large technology companies and virtually all "mega-vendors", e.g., Microsoft, IBM, have a dedicated organization whose job it is to uncover problems that may not have even surfaced yet and search for likely solutions to those problems. I haven't seen research indicating at what size a company typically creates a specialized research organization, but I would say it becomes more common North of a few thousand employees.

As we product managers often find solving today's problems more than full-time work, the potential synergy between research and product development should be fairly obvious. In an ideal world, research could anticipate the impact of key trends, both technological and otherwise, and explore how they could be addressed with technology, enabling breakthrough customer solutions that are developed and delivered by product groups. However, with a notable exception or two, I've rarely observed these two organizations working together in a way that I though was highly effective, i.e., in a way that generated significant revenue broadly from product innovation.

The disconnect between research and product development had various root causes in different organization (perhaps fodder for a future post), but there were common traits I saw in these sub-optimized relationships:

1. Lack of mutual understanding

Even though both product managers (the people who should be accountable for product development) and researchers are essentially problem solvers, the end products of their efforts and the way they approach their work are radically different. Each have complex, domain-centric concepts, terminology and approaches that often seem to be completely lost on the other, even though there are a host of analogous goals and processes between them.

2. Motivations not aligned

In an earlier post, I described the concept of business motivation, i.e., vision, mission, goals, objectives. In my experience, research has little or at best anecdotal knowledge of product teams' vision and objectives. Often, product teams, heads-down trying to ship software, have little or no idea about research's mission or their investments.

3. Ad hoc engagement model

In my experience, very few product teams engage with research as a matter of standard practice. While one can easily make the argument that engaging with engineering and marketing has much higher priority short-term, completely overlooking research strikes me as a potentially wasted opportunity.

Perhaps the most intuitive (although admittedly oversimplified) way to contrast research and PM is to consider their typical time horizons: while research is focused on solving tomorrow's problems, PMs and their product development teams, in practice, spend most of their time solving today's. I know progressive PMs may push back on this statement, rightly claiming that PMs have an obligation to anticipate what their customers will need a few years in the future. However, the benefit of having a group of very bright people focused on problems and possible solutions that likely lie beyond the last milestone on their product roadmap seems self-evident.

Bringing research and product development into alignment is not a trivial exercise but is definitely possible and can be highly profitable. In a future post, I'll suggest they key ingredients to getting these groups working together to bring breakthrough solutions to your customers.

Has research benefited your customers? If not, why not?

Next post: The brilliance of demonstrating benefits over features

The brilliance of demonstrating benefits over features

I was recently checking out cameras on Amazon.com and came upon the Canon G16. As I was skimming through the voluminous information on its features, I saw a demonstration of value that genuinely impressed me. The feature being described, autofocus, has been standard on digital cameras for as long as I can remember. I take a lot of pictures and almost never focus the camera manually. Nothing remarkable so far. It turns out what differentiates cameras isn't whether or not they have auto focus, but how quickly the camera can focus on an image. Think about that for a second: how can you promote the speed of autofocus in print? Do you create impressive tables full of scientific statistics? Do you say that it's really, really, really fast?

The marketing folks at Canon came up with a simple solution to communicate the benefit (not just the feature) of autofocus speed in a way that will immediately resonate with their target market: non-professionals who take pictures. I would assume almost all of us (especially those with young children) can relate completely to the two simple pictures below. The message? Use our camera and you'll stop missing pictures. It's interesting to note that the message is communicated in a fraction of a second at a basically subconscious level.

What did I (re)learn?

• Listing tons of stats with decimal-precision and colorful graphs probably isn't the most effective way to communicate technical features to non-technicians (technical buyers love pages of stats, detailed scientific bench marking etc.)
• Exploring particularly frustrating aspects of a general problem can sometimes reveal a message that will resonate almost viscerally (not just logically) with your audience (and tip the scales toward "buy")
• Creative but simple approaches to demonstrating benefit and not features may run counter to our sometimes geeky intuition and instincts, but will almost always result in a more compelling message, especially to non-technicians.

Although I believe a marketing professional should be responsible for public-facing messages etc., we as product managers need to understand ideas like "benefits over features" as we a.) should collaborate with marketing on the crafting of messages b.) are often called upon to promote our product.

Next Post: Demystifying the Go-to-market for Product Managers

De-mystifying Go-to-Market Strategy for Product Managers

I've been a product manager for about 15 years, mostly in big shops with mature marketing organizations. Although it's clearly not fair, I've developed an aversion in that time to the seemingly non-stop  flow of buzzwords that the marketing field seems to generate. It was probably about 10 years or so that the term "go-to-market" was thrust on my radar by a senior manager in our product group. While I had certainly heard it before, I had discounted it as just more marketing babble (I realize many marketers have their own feelings about product management babble). Anyway, I asked what it meant and received an answer so nebulous that I wasn't sure if I was just too simple to grasp it or if my "jargon meter" was right on. Since then, I've come to embrace the critical role a go-to-market strategy (or simply "go-to-market") plays in ensuring product success. As a matter of fact, I would go so far as to say that a poorly conceived go-to-market may be the most consistent reason products fail, especially those from software startups.

Let's start with what I consider a reasonably good definition from Wikipedia: a go-to-market "refers to the set of integrated tactics which a company will use to connect with its customers/business and the organizational processes it develops (such as pricing and contracting) to guide customer interactions from initial contact through fulfillment." My cursory research uncovered all kinds of definitions, at times so broad that I couldn't distinguish a go-to-market strategy from what I've always considered a marketing strategy. In my opinion, a marketing strategy and a go-to-market  are related but different, the go-to-market describing how the target markets in the marketing strategy will be made aware of your offering and how they will get their hands on it. A marketing strategy is much broader, including researching market size, creating advertising etc.

Put simply, a go-to-market determines how people are going to find out that you have something they would benefit from buying and how they'll get it. There seems to be consistent blind-spot in human perception that I'll call the "Field of Dreams Syndrome", i.e., if I build it, "they"  will come. Very painful experience across multiple facets of commerce has demonstrated clearly that this is the case a very, very small percentage of the time. Oddly enough, I think this syndrome is related to an adage as old as time about love being blind. We often become so enamored of our own ideas and (our perceived) cleverness that we simply cannot imagine that others won't feel the same.

Perhaps a more intuitive way to understand go-to-market is to consider a fate that has befallen countless internet startups: They dream up a great idea, pull a few bucks together to develop it and then upon launching it realize that they have no idea how the customers they've dreamed of will discover their amazing site or app. Their "baby" is lost in a sea of other sites/apps and the "viral adoption" they hoped would happen is, in reality, a one-in-a-million proposition. A poor go-to-market can handicap any type of business. I know someone who developed a software solution that aimed to make it much easier for private doctors to run their practice. Although getting the solution built was no walk in the park, it turned out that the real challenge was getting in front of enough doctors to drive sufficient revenue to keep the lights on. It's remarkable and unfortunately very common for folks to focus on the problem their solving and the solution their providing while giving almost no though as to how people will find out about the value their solution provides and how they can get their hands on it.

Go-to-market is also highly relevant to existing products and is often revisited for each release. Just because you have established mechanisms for raising awareness and delivering your solution to customers doesn't mean they're optimal. For example, if your company's sales organization is struggling to get in front of decision makers in a given market segment, finding a partner that has developed close relationships to these people might increase sales.

Now that we know what a go-to-market is, how do you go about creating one? What's in it? As you might expect, there are multiple answers to these questions. In an upcoming post, I'll talk about defining a go-to-market, particularly as it relates to the participation of product managers (who, by the way, are NOT typically accountable for defining it).

In researching this topic, I found the first few slides of this presentation particularly concise and informative. As they say, a picture is worth a thousand words...

Next Post: Hitting the ground running as a new PM

You can find more information about me (including upcoming training dates) at www.prickril.com.

Hitting the ground running as a new PM

I absolutely love this post by Rich Mironov on what to do as a PM when you assume responsibility for a product. I've done a fair amount of moving around in my career, between continents, companies and departments so wish I'd had this type of guidance much earlier in my career. The suggestions Rich makes seem right on to me. I heartily concur with the thought of learning your product, for example. One of the quickest paths to credibility with folks from development to executive leadership is knowing your product end-to-end better than any of them. Rich's post got me thinking a bit about the drill I've developed for taking over a new product. I thought I'd share a few of my hard-won insights.

Before You Accept the Position
You should do these things before you agree to accept the PM mission:

1. Understand precisely what management expects from you in your first 100 days.
Whether you're a product manager at a 3 person start-up or a head of state, this initial period often sets the tone for your first few years. Cogitate on these expectations thoroughly -- you'll spend your first couple of weeks (or more) determining how or if you can make these things happen. I would recommend asking this question explicitly of your to-be manager and his manager. If they can't provide you with a clear set of goals, you should proceed very cautiously or not at all; whether consciously or not, you might be being set up to fail.

2. Determine whether your product is "a star, a dog or a zombie" (to use Rich's terms).
Rich is right on about this, but I would suggest you do everything reasonably in your power to determine this before you start. Getting this information may require asking some inconvenient questions, particularly of senior leaders, one or more of whom may be in your prospective chain of command. You should be tactful but not shy about asking for this information. Execs and managers aren't the only source of information on this topic: the more junior the interviewer, the more likely you are to get an unspun perspective. Tread lightly as you research this topic, but make sure you have a good idea of what you're up against and be sure you're ready and willing to face it. It is not uncommon for a change in PM positions to belie deeper problems within the product team. Asking why the person previously in the position left it is a good idea. Tactfully asking others in the interview loop what they think of your predecessor and the PM team in general can also be enlightening.

3. Set expectations regarding your needs during your first few weeks.
If you set the right expectations, you can likely get things done in the first few weeks that you will never get done once you're sucked into the vortex that is most PM jobs. Tell your manager that you want time to learn how to use the product, including taking formal training if necessary. Tell her that you expect to participate in some sales calls and that you may need to travel to talk to customers and your counterparts in the field face-to-face. Realize that you're in stronger position to request these things while you're still being recruited that you will be on your first day at the office. Requesting reasonable investments that will accelerate your acclimation, far from alienating management, can demonstrate a maturity they will often respect.

During Your First Week on the Job

1. Talk to support and review customer tickets
I would suggest before you talk to anyone else, you spend some quality time with the support team, reviewing open tickets and understanding related trends. The number of customers that have opened tickets can give you a realistic picture of how many customers are really using your product, i.e., putting it through its paces in production rather than letting it collect dust (and possibly bad will) on a shelf. Looking for trends in tickets and talking to support professionals can give you a quick impression of the overall quality of the product, exposing problem areas. Getting insight into customers' experience with your product can also be helpful when you speak to them. If there was a relationship-impacting issue in the recent past (or an ongoing one), it's best to know before you get to the customer site.

I recommend that support is the first stop on your initial "good will tour" as understanding the support situation allows you to see through the sometimes distorted view of people within the organization who, over time, have developed a misinformed or even self-serving picture of the health of the product. As I alluded to before, if marketing or executive leadership tells you that 5,000 enterprise customers have bought the product, why have only 30 customers opened tickets in the last year? If development tells you they're on top of quality, why is there a huge spike in tickets after each release, including the reappearance of supposedly solved bugs. Why isn't the number of high severity tickets trending downward?

Arming yourself with data can dramatically increase the fidelity of your overall impression of the product. You should, of course, avoid using this information as a weapon as you talk with others, avoiding confrontation initially, actively keeping yourself in listening mode as you make the rounds.

2. Understand who your critical stakeholders are other than customers
While it's tempting to rush into dialog with customers, you should also do some deep thinking and exploration regarding other stakeholders that are critical to you success. Sometimes they are unexpected. Is your product on the forefront of company strategy or is it in a more supporting or even declining role? Product management of more successful, on-strategy products may be important allies -- develop relationships with them. Is sales highly incented to sell your product? Are they aware it exists? Is there an up-and-coming exec that has it in for your product or management? A change in PM sometimes creates the opportunity for a reset of previously rocky relationships -- take advantage of this "honeymoon period" and invest your time in the stakeholders that can contribute most to your and your product's success.

3. Ask development leadership specifically what they expect from you
Having helped implement product management and Scrum multiple times, I've been the subject of some mighty big expectations from development, some of which I wasn't even aware of when I failed to meet them! During your first week, sit down with development leadership, both those with explicit and referent power, and ask them directly what they expect from you short-term and longer term. If your plans don't align with their priorities, you've got some thinking to do. Disappointing or even alienating the development team from the beginning can be an unrecoverable (fatal) error. That having been said, you need to set realistic expectations about what you can accomplish and continuously manage their expectations. The best laid plans of new PMs can be set asunder once your business cards loose the "new" smell and you're pulled in a hundred different directions. If circumstances change and you can't deliver what dev (or other stakeholders, for that matter) expects, explain why priorities have changed and readjust expectations if you can.

What are some of your tricks and techniques for making the most of your first several days on the job? I would be willing to bet someone reading this can benefit from our input in the near future.

• Related Post: How to become a software product manager
• Next post: Demystifying Go-to-Market Strategy for Product Managers

You can find more information about me (including upcoming training dates) at www.prickril.com.