Training the Product Manager: An Inventory

I recently started a thread in the enormous LinkedIn Networking Product Management group about appropriate training "topics" for product managers. As a provider of product management training (see www.prickril.com for details), I've been trying to assess how broad the need for training is in the product management community. I seeded the discussion with what I considered a short list of no-brainers, expecting a few folks to chime in with another topic or two:

• Core product management (product life cycle, release management, product strategy etc)
• Negotiation
• Presentation Skills
• Leadership
• Business Planning
• Product marketing.

I was extremely gratified to see far more responses than I expected (in the low 20s as of this writing). In my original post, I committed to consolidating the results and publishing them. I captured feedback in a mind map in a public Google Drive folder so that it will be available to anyone interested as it evolves. I've posted it as a PDF and a native XMind file. You can view/edit the XMind map if you so choose with the free version of their software.

I added comments to many nodes, but the general categories of training I identified were:

• Product Management
• Adjacent (topics related to other disciplines like marketing and sales and general professional training)
• Technology
• Organization-specific
• Other

I wrestled with categorizing some of them so I'm sure others will have a different opinion. Based on feedback I get and new "discoveries", I'll update the map over time. My sincere thanks to all who chimed in and all that will.

I'm looking forward to seeing the map evolve with input from an even broader community!

Overview of a Product Management Assessment Framework

In a previous post, I enumerated what I consider to be the most important criteria for evaluating a framework for assessing a product management organization, particularly one focused on software. In this post, I'd like to outline the approach to product management assessments I've defined with these criteria in mind. I'm looking forward to feedback and discussion on the topic.

In an effort to be comprehensive, I've based the assessment approach on the idea of organizational maturity, a blanket concept that I think is reasonably intuitive. To keep things simple, the assessment generates a single value or score for the maturity of the product management organization. The organizational maturity score is a weighted average of 3 "dimensions" described below.

Dimension 1: Process Maturity

Process Maturity measures how well the organization understands, manages and executes its business processes. A business process converts business inputs to business outputs. Business processes don't have to be described with detailed graphical models and reams of documentation to be managed. What's important is that the organization understands which processes are important, have assigned ownership and is continuously improving them. I used ISPMA's framework to identify the "menu" of key process "elements" to be analyzed. Organizations should probably avoid analyzing more than 5-7 processes at the same time.

Each process can be assessed in general terms, e.g., is there a clear owner, as well as process-specific criteria, e.g., are roadmaps generated for different audiences (typically, a sign of maturity). These criteria can be scored, from 1 to 5 for example, so that an average or weighted average score can be calculated.

In terms of key process deliverables, I use a list of types of information organizations should be gathering rather than relying on a predefined set of artifacts. Checking process deliverables such as roadmaps and strategy papers for quality and completeness can help identify process that are suboptimal.

Dimension 2: Professional Competency

The professional competency dimension helps determine if the right people with the right knowledge and skills are executing the product management function. My framework uses a questionnaire that is filled out by product managers and their managers ranking their proficiency with various product management activities. My questionnaire is based on the Dimensions of Competency I've described in this blog (business leadership, product definition and product promotion).

Interviewing product managers, product management and executive leadership is also important, allowing an experienced assessor to determine if those doing product management have the appropriate background and personality to perform at a high level. There is clearly a subjective element to this dimension, but I don't believe any form or tool can replace experience and judgment. I also think it's important to interview members of other disciplines such as development, marketing and sales regarding the effectiveness of the product management organization.

Dimension 3: Organizational Setup Effectiveness

The effectiveness of the organizational setup is probably the most complex of the dimensions. At its heart, it explores if the organization is set up in a way that promotes success. For example, structural analysis looks at to which discipline the product management organization reports. I believe that, ideally, the functional and technical perspectives are separated organizationally. I talk about these different perspectives in my post about the "piles" of product management.

Organizational setup effectiveness also captures aspects such as professional development, engagement between functions, e.g., marketing, sales, and completeness of product development disciplines. For example, a highly effective product management discipline will ultimately fail if marketing or sales are underdeveloped or even absent.

Bringing it All Together: The Maturity Dashboard

Via simple tools, observation and interviews, scores are generated for each dimension. Weights are assigned for each dimension with the weighted average representing the organizational maturity score. Although this approach is not purely scientific, it is highly approachable and supports prioritization of improvement efforts, i.e., the efforts that have the highest impact on the organizational maturity score are those that should be addressed first. This idea is predicated on the idea that the dimensions and the information gathered truly represent critical aspects of the product management discipline.

The figure below shows a fairly simple representation of what can be a large, complex set of data. I've defined the different levels of overall maturity informed by the maturity levels found in the Capability Maturity Model (CMM).

Note the weights assigned to the dimensions to the left of the labels in the table at the bottom. These are examples of values that can be easily adjusted for a particular client. Some organizations might emphasize Professional Competency (or any of the other dimensions) more heavily so would adjust its weight accordingly. 

Assessing the maturity of an organization is an inherently complex problem. The framework I propose attempts to balance objective data with the judgment of an experienced assessor. A great deal of qualitative and quantitative data would, of course, accompany the dashboard.

So what do you think? Is it similar to other frameworks you've seen? What do you see as the biggest gaps? Do you think this approach could be valuable with your organization? 

Previous post: Does your organization really know what it's taking to market?

Does your organization really know what it's taking to market?

Having been exposed to a fairly large number of product organizations, I continue to be surprised at how rarely they explicitly define a set of concepts representing what it is they take to market. Terms like "product" and "solution" are bandied about but often it seems no one can point to a common definition, resulting in multiple people and organizations having their own definitions and associated expectations regarding these concepts. Having clear, consistent definitions for the things we take to market help keep the entire organization, from executive leadership to developers, on the same page and can have important implications for assigning accountabilities. In this post, I'd like to offer a set of simple concepts that have served me well. If used consistently, these definitions can alleviate some of the confusion I've seen time and time again in product organizations all over the planet.

• An offering is an umbrella concept representing anything that your organization takes to market for customers to consume. The rest of the concepts in this list are types of offerings.
• A product is a good, virtual or otherwise, that is developed and delivered to multiple customers in essentially the same form. Managing products throughout their life cycle presents challenges that I believe are an order of magnitude greater than managing deliverables from a customer-specific project. Transitioning from single-customer project deliverables to product delivery is a topic I've addressed previously in this blog.
• A service, in the context of offerings, is work performed by people for customers, whether it involves "knowledge work" or physical labor. Services are an under-served offering in many organizations, representing a way to add incremental customer value while strengthening customer relationships.
• A solution bundles products and services (and other solutions!) to solve customer problems. Solutions are very often customized heavily for individual customers. Market solutions are defined a priori and promoted in the market. Customer solutions are an instance of a solution delivered to a specific customer.

Based on these definitions, I've found that many product managers, especially those in the B2B space, are actually managing solutions. Acknowledging this fact can help everyone in the organization appreciate the scope and complexity of the work the product management organization is doing. 

I'm not sure that it's critical for every organization to adopt the exact same set of concepts or terminology, but it would be nice! I think it's more important that all product development disciplines (PM, marketing, sales) and executive leadership be on the same page. Ideally, this same or very similar terminology is used to describe offerings to customers and prospects.

What do you think of these definitions? Are they similar to the ones your organization uses? Does your organization have an explicit set of shared definitions?

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

Criteria for Assessing a Software Product Management Organization

In a previous post, I talked about assessing products as they are being developed. In this post, I'd like to talk about a different kind of assessment: assessing (or "auditing" as some others call it) a software product management organization. Formal assessments are often requested by leaders of an organization who are concerned about the performance of the product management function. What I've realized since I began thinking deeply about the topic is that every time I've joined a new company, I've done a mental assessment to size the place up. When I began developing my assessment framework, I found myself trying to articulate or externalize this tacit mental model.

Before sharing my approach, I thought it made sense to share what I consider the primary requirements or criteria I would use to determine if the framework was ready for primetime. Whether you eventually agree with my approach or not, I hope these criteria can help you assess the multiple assessment approaches you are likely to encounter in the market.

An assessment framework or approach should be:

Simple

I believe the approach or method used to assess the product management organization should be reasonably simple: not to many heady concepts or moving parts. This requirement helps ensure those commissioning the assessment can easily understand the approach and its outputs. It also allows one to deliver an engagement in a fairly short period of time. My goal was to be able to deliver an assessment within a couple of weeks or less.

Comprehensive

I've read about assessment approaches that focus on the knowledge and skills of product managers. Although I too think professional competency is critical, it is just one the elements that impacts organizational effectiveness. By the way, I believe that the goal of the assessment should be to measure the organization, not simply the people in it. For example, I've spent a lot of my career creating platforms that model and execute business processes, so understanding the maturity of processes is important to me (and most organizations, I believe).

Quantifiable

I decided early on that beyond the qualitative aspects I can assess based on experience and intuition, measuring subsequent improvement would require that key elements of the framework be reducible to values that could be measured. That doesn't necessarily mean that the values are valid from a purely scientific perspective, but that changes in performance, both positive and negative, can be tracked over time in a convincing way.

Flexible

Experience with quite a few product management organizations has taught me that each organization values different aspects of the discipline. An assessment framework should be flexible enough that it can be adapted to incorporate an organization's priorities and culture.

Transferable

Although I believe it's difficult to generate assessment results that support an "apples to apples" comparison of any two product management organizations, the framework should capture common aspects of the product management discipline in such a way that reasonable comparisons can be made. This criterion is particularly important when assessment multiple organizations in the same company, e.g., different business units.

In a future post, I'll enumerate the key elements or "dimensions" I've chosen for my framework based on these criteria. I've shared my approach with several people whose opinion I value and am so far encouraged.

What is your experience with assessing product management organizations (particularly in the software domain)? What requirements or criteria are important to you?

Previous post: Overlooked Sources of Product Management Power

Overlooked Sources of Product Management Power

The idea that knowledge is power is as true as it clichéd. I've noticed there are several sources of very powerful information that are often overlooked by product managers:

CRM System
If your organization has implemented and maintains a customer relationship management system, you should do your best to get access (even if it's "read only") and use it as a resource to understand what's going on with customers and prospects. You'll very quickly discover that the information stored in CRM can give insight unavailable almost anywhere else. Ideally, PMs should update CRM systems when they interact with customers so the entire account team is aware of discussions, issues etc. I'm amazed at how seldom this resource is leveraged (and how often customers get the impression that your company's right hand doesn't even know the left hand exists).

Customer Support Database
In my post on things to do when you take over a product as a PM, I discussed the importance to PMs of understanding support issues. If you're not browsing support tickets at least once a week and don't regularly engage with support to understand their pain, you're missing a massive learning experience. Investing 20 minutes a week reading about customer issues can inspire you with ideas and arm you with the data you need to influence others, whether they be execs, development or other PMs.

Business Motivation
Understanding the explicit vision, strategy and goals of your organization and/or company can give you insight that helps you define a product that is on-strategy and gives you an advantage when communicating with execs. Think about your most important executive sponsors and ask yourself "Do I really understand specifically what they're trying to achieve?" The sad truth is that most organizations don't have an explicit motivation model. In many cases, you'll have to use your network to get access to presentations or strategy papers that may not be widely disseminated. In others, you may have to ask execs verbally. Regardless, going a level deeper than the vision statement on your company's Web site can, at the very least, allow you to position yourself and your product much more convincingly.

Annual Report
Let's face it, almost no one reads a significant proportion of the content in an annual report. Regardless, as a PM you can often extract nice little nuggets of knowledge that help you understand the big picture, including a sense of the business performance of the entire company. It is not at all uncommon for us to be so focused on our product, that we forget the company is doing a million other important things. How many times have you been caught off-guard by a customer or another "external" that was more aware of developments at your company than you were? Taking time to read the annual report and memorize a few key factoids and maybe even a few financial figures may present you with the opportunity to demonstrate that you're a strategic thinker, impressing people with little more than an offhand comment about dwindling margins in Asia.

There you go, 4 sources of often untapped power. Happy reading! What other sources can you think of?

Product Manager vs. PMINO

My career has taught me that in the context of different continents, countries, industries, companies and organizations, titles mean precious little. I've worked for companies that were overrun with vice presidents and/or directors and in others where those titles actually meant something.The inherent ambiguity of titles, as well as the plethora of definitions of product management, led me to ponder what it really means to be a product manager, rather than a PMINO (product manager in name only {pronounce puh-MEEN-oh}). Here's my list of the key criteria I used to determine if, from my perspective, someone is really worthy of the title of product manager.

In my book you are really the product manager if (and only if) you:

Own the roadmap
The roadmap is the incarnation of the vision, linking it to delivery of value to stakeholders. If others are defining the roadmap, there is a significant possibility that you are a PMINO. Owning the roadmap doesn't mean that  you unilaterally define what will ship over the next few "turns of the crank", it simply means that the roadmap cannot be communicated to stakeholders without your buy-in (however coercively that buy-in was achieved).

Set release priorities
While I'm a big believer in grand visions and audacious goals, I'm an even bigger believer in shipping products to customers that meet business objectives. If you aren't the primary driver and gatekeeper of release priorities, there's a good chance you're a PMINO. Few product managers are so influential that they define priorities ex cathedra, but if releases don't reflect your priorities and even your style, you may have slid across the continuum of amorphous disciplines toward the "proJect manager" zone. You have to ask yourself, "Am I in the driver's seat or am I really in the back seat.", and make sure you can live with the truth. A relatively large number of people can dutifully execute on another's priorities; a proud few (product managers) can take accountability for release priorities and win in the market.

Define the product vision
When I began writing this post, I thought that, coming top-down, vision would be the first criterion addressed. The truth is, even without a vision, some organizations can generate impressive results. If we're really honest, not that many companies, business units or product groups really have a meaningful vision. Regardless, if a vision has been defined and you weren't instrumental in its definition, you just might be a PMINO.

Are acknowledged as a leader by the product development team
While this is probably the most nebulous of the criteria I've proposed, in my experience, a few intelligent questions posed to the right members of the extended product develop team (development, marketing, sales) will quickly indicate whether you are a real product manager that leads or simply someone carrying the title. This criterion underscores one of the most difficult aspects of being a product manager: You lead many but have authority over almost none. If you haven't become the spiritual leader or even guru of your product, you, in my mind, have some work to do. Above all else, product managers are leaders. By definition, leaders have followers. While the world isn't anywhere close to being this black and white, as a guideline, you as a product manager should probably be doing more leading than following.

In closing, being a PMINO isn't necessarily a reflection of individual talent or initiative. The best of product managers can find themselves in situations in which they've been dis-empowered to the point they don't have the influence on the product they should. For this reason, it's a good idea to use the criteria above as a checklist from time to time to assess if you're charter has, over time, been reduced to a point that you're following more than leading.

What do you think of my criteria? What would you add? Have you met PMINOs? Where do you fall on the PM/PMINO continuum?

Assessing software end-to-end while it's still "in the oven"

Every once in a while, we come across a best practice that generates so much value it becomes part of our product management toolkit. I'd like to discuss a practice related to evaluating software products that are under development that with a reasonable amount of effort:

• Improves overall product quality
• Generates great ideas, both large and small
• Increases executive buy-in to your product and development efforts
• Provides clear focus to the development team that creates results and changes behavior

This practice can be thought of as an extension of Scrum as it fits well into the rhythm of sprints and the idea of always having a shippable product, although in theory it is not methodology- or framework-specific. It involves semi-formal, end-to-end reviews of products as they are being developed. We called these reviews "assessments", not to be confused with the practice of assessing the effectiveness of product managers or product management organizations that is often called an assessment or audit.

Our practice worked thusly: Toward the beginning of the release, we would identify milestones at which we would convene what might be characterized as a workshop to experience firsthand using our product throughout its life cycle (our product was on-premise).These were different than usability tests, unstructured testing or "bug jams" in terms of the emphasis on the life cycle, the roles of the participants and the way we conducted the exercise: a multi-function group of users working through predefined scenarios at the same time in the same place.

Perhaps a quick description of a typical assessment is the easiest way to describe this practice. Product management (with the help of Q and others) would define scenarios including installing, configuring, using and even uninstalling our software product based on the features that we felt were mature enough to test. We typically wrote simple scripts describing the steps at a fairly high level which were distributed to the participants, which included product managers, executives, people from sales and marketing and even people from other product groups. We would typically block an entire day, scheduling it enough in advance to ensure broad participation. We would reserve a room with plenty of space with all the hardware necessary to execute the scripts. A few of us with deep knowledge of the product, including representatives from development, would be available at all times in the room to help participants with issues they inevitably encountered, capture feedback and help development address issues that were identified. Beyond helping participants, predetermined members of the development team were at the ready to address bugs and other issues as quickly as possible.

The first script usually involved installing the product from scratch, something that probably doesn't receive enough emphasis in exercises like usability tests. Having novices attempt to install the product exposed complexity in a very painful way, giving execs and team leadership insight into a process that isn't always on their radar. Prerequisites that had to be installed separately or complex installation steps requiring lots of arcane configuration information helped us realize what we were putting our customers through. Truth is, in some cases, we barely got much beyond the install in the allotted time, especially early in the release.

In terms of testing features and functions, we usually scheduled most of the time for participants to execute the scripts. However, most people, especially execs, love to go off-script. We also allocated time for freeform "wandering" through the product (especially as we got closer to the release date).

Elaborating on the points at the beginning of the post, this approach commonly generated the following benefits:

• We found that having some formality around our assessments, scheduling them in advance and inviting leadership provided, to say the least, significant focus for the entire product development team (it seemed to particularly get dev's attention)
• Quality improved as many bugs were addressed almost immediately (with an exec waiting for the fix!)
• Stakeholder buy-in increased as execs and others outside of the product development team understood the product better and became acquainted with the cools things it could do
• At least one really good idea was generated, sometimes regarding neglected parts of the product such as configuration
• The extended product development team (top to bottom) got closer

Is your organization doing this type of multi-function, life cycle-focused, script-based assessments? Do you think it would work for you?

Positioning Product Management with Executives

The fact that many of us product managers struggle at times to explain to lay people what we do is quite well documented. Many of us have a glib answer like "cat herder" that we quickly follow up with a more reasonable explanation. Whether people really understand what we do is very often not critical. To avoid long-winded explanations that tend to confuse more than enlighten, I typically tell people I do "software" and leave it at that. However, for a variety of reasons, you may someday find yourself with a need to explain to executive leaders what you do and why it's important. In rare cases, it may be because you are joining a company with no product management function and you'd like to act as an agent of change. More often, you'll encounter specific execs that simply don't see the value of product management, perhaps because of a technical bias, painful experiences, lack of exposure or, in some cases, pure orneriness. Regardless of the foundation of their perspective, the sad truth is that if they remain uneducated, they may very well take steps, consciously or not, to marginalize your contribution or diminish your charter. In these cases, a convincing argument in favor of product management is critical.

Before I address explaining product management to executives, it might be worthwhile to think about how you should talk to execs in general. While no two execs are identical, I've learned certain messaging techniques that have served me well in multiple companies on multiple continents. Having been involved in a few incubation projects and new product development, I have spent a great deal of time "pitching" execs and have the gray hair to prove it (one of the founders of one of the largest software companies in the world got up in the middle of one of my presentations, turned his back, and made himself tea!). Here are a few guidelines to consider when talking to "the suits":

• Keep your message as concise as possible (you should think of extraneous words and concepts as attack surface)
• Demonstrate that you are aware of the strategic implications of the topic you are presenting (because the message will likely be received in the context of a strategy that extends beyond your topic)
• Avoid buzzwords, but try to use terminology that is familiar to execs and that underscores the previous point

Keeping these things in mind, it is critical that you avoid explaining product management to an exec the same way you might explain it to your mother or the chatty person sitting next to you on a long flight. When explaining product management to senior leaders and executives, you should come top-down, not evolve the story bottom-up. The story line goes something like this:

• It is important for a company to have a compelling vision and a strategy for achieving it
• In product companies, each product should have a vision and strategy that supports the corporate "motivation model", i.e., vision, goals, objectives
• Product management is responsible for defining and executing on strategy at the product level

Once you've established this foundation, you can selectively talk about how you orchestrate the activities of other disciplines, engage with customers etc. But be clear: your job is to underscore that product management is a direct extension of corporate strategy, ensuring the right products ship at the right time for the right cost.

While I'm on the subject, perhaps the reason so few people understand the value of product management is that we tend to explain it bottom-up rather than top-down. I believe this is the case and have some ideas about how we as a community can emphasize our strategic, rather than tactical, contribution. More on this in a future post.

Managing Product Creativity with the "Motown Model"

I recently listened to a brilliant interview on satellite radio with Smokey Robinson, a legend in music. Mr. Robinson was at Motown Records from the beginning and almost as an aside provided some fascinating insight into a creative process that generated an unfathomable number of great songs from some of the greatest artists of all time.

I guess there's a chance that younger folks or people who haven't been exposed much to American culture don't know about Motown records. For the rest of us, an almost incalculable number of hits from folks like The Supremes, Stevie Wonder, Lionel Richie, Gladys Knight and Smokey himself make Motown a modern music institution.

In describing how songs were composed and selected, Smokey outlined what I consider a compelling best practice for managing creative people that leveraged collaboration and an appropriate amount of structure to deliver greatness. He talked about how there was a special meeting held every Monday morning for only creative types: no folks in suites from sales or distribution. The meeting began promptly at 9:00, at which time the doors were locked. If you were late, you were out. At the meeting, composers would bring the songs they were working on to be reviewed by other composers and producers. Suggestions for improvement were made as necessary with the composer bringing the song back for further review in the next meeting. The group would vote on which songs should be recorded and released.

I see no reason that a similar approach couldn't be adopted by product groups trying to ensure the right features are developed and shipped. Here are what I consider the key learnings from the "Motown Approach" Smokey described:

• Creativity was taken so seriously it was addressed in a regular, dedicated meeting
• The meeting was limited to creative types actually involved in making the music (not necessarily marketing, selling and distributing it).
• The meetings had rules and a purpose -- they didn't involve a bunch of unfocused creative types trying to out-innovate each other. If you didn't take the process seriously, you didn't participate.
• The goal of the participants was to help composers create the best song possible based on the Motown aesthetic (they understood their brand and expectations of it). I would assume in general the group was more supportive than it was judgmental.
• Ideas were transparently voted on. I would assume that while some participants didn't agree with the decisions that were made, they didn't have the feeling that their creativity was being judged by a few leaders in a smoky (pun intended) back room.

So how about it product managers? Why not hold regular meetings at a rhythm that makes sense to your organization where creative types can share and collaboratively refine ideas? Why not introduce some level of voting in feature selection? There are many tools available to product managers that can make this process easy and transparent (including a white board or Excel!). Perhaps some simple rules could ensure that participants take the process seriously and only those willing to constructively  contribute are included. Maybe there's some value in limiting participation to folks that are genuinely willing to contribute creative ideas, rather than the folks more focused on getting the product "off the shelf".

I haven't test driven this approach yet, but would imagine with a bit of good faith effort and a bit of leadership (likely from product management), it could result in more innovative products and a more cohesive team. I can only assume that some groups have already adopted similar approaches.

What do you think of the Motown model? Is your product development group actively managing creativity? Are the right people "at the table" when it comes to creativity and innovation. I would love to hear about your experiences.

Next Post: Not a product manager in sight...

Not a product manager in sight...

I've had the good fortune to work at companies that, at least over time, have acknowledged the importance of product management in developing great products. In fact, most folks at big shops would have difficulty imagining releasing software without a PM on board. It therefore strikes me as extremely odd to come across product companies with hundreds of employees (or more) that haven't yet adopted product management as a role in their product development process. I've witnessed this phenomenon but had never thought that deeply about how it happens. During a very enlightening conversation at the Product Management Festival in Zurich in September with Siobhan Maughan, of IntegratedThinking, she articulated very concisely what is probably the canonical evolution of small but quickly growing companies that finds them waking up one day with complex, successful products (or even portfolios) but no product managers. I'd like to elaborate on the few sentences she shared.

To understand this evolution, we have to go back on these companies' timelines to the earliest, exciting days when the combination of a great idea, a bit of funding and big dreams was enough to keep a small team working too many hours to get V1 out the door. At this stage in most companies, there's a visionary leader who understands the market and has a vision for addressing its problems. Although this person rarely considers herself a product manager, that is exactly the role she fulfills. Via personal experience or an innovative vision, this person articulates the requirements and works with development and others to define the solution. She drives validation with stakeholders and helps development adjust the features as necessary. Part of the reason this person doesn't consider herself a product manager is that she is wearing a multitude of other "hats": CEO, marketer, head of sales, HR etc.

Now let's fast forward a couple of years. If the fledgling enterprise has survived, we can assume V1 made it out the door (almost) on time and with lots of elbow grease and a few apologies here and there, led to a much better V2. The visionary leader from the early days is now operating as a proper CEO, pulled in a million different directions as she participates in strategic sales calls, lobbies banks for bigger lines of credit and ponders leases on yet more office space. The head of development, who was there from the beginning, has taken over most of the work of driving engineering and gathering requirements. Because there is such a long list of features that were cut from earlier releases and so many urgent requests from important customers and from sales people frantically trying to close deals, the development team starts to get out of touch with the market and spends less (if any) time proactively talking to customers. Throw in personnel changes in a couple of key positions and you can quickly end up with a development organization that is struggling to keep its head above water, completely in reactive mode relative to customers and dangerously out of touch with non-technical trends in the market. As sales level off and competition increases, the company starts to ponder how it can make its product more compelling. Sooner or later, someone suggests introducing a product management team and a significant cultural and procedural shift gets painfully underway.

It would seem that the simplest way to avoid this problem is to include a product management function from the get-go. I've read totally divergent perceptions about how common that practice is. One post I read recently implied that hiring a product manager is typically the first thing startups do. This idea runs contrary to my personal experience. More often than not, I see small groups of bright people overlook the fact that converting an idea into a shipping product is a skill set that cannot be developed from scratch in a few months. The startups I see have people filling the roles of visionary, business guy, technical guy and eventually marketing guy, completely overlooking the role of product manager. In my opinion, this can be an expensive or even fatal mistake.  (I've witnessed some pretty expensive "rookie errors" first-hand).

What is your experience? Have you been surprised by product companies with no product managers? What do you think the role of product management is in startups?

Next Post: A New Definition of Product Management

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.