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