What’s the deal with Software Product Management?

OK…this one has been bubbling inside me for a while, and tonight I decided to lay it out and see what feedback comes in. I’ll put on the flame proof suit now.

In our little world, we (Product Managers) think we are all that. We view ourselves as a critical component of the software development process.

How would developers know what to do if we weren’t around to provide market and product requirements?

How would the “sales droids” make their quotas without the help of Product Managers on those big deals?

Who else could define a coherent product strategy that is both aggressive in the market but achievable with limited resources?

Who else has the ability to be as technical as the engineers, as sales-savvy as the sales team and as hip and aware as the marketing team?

We are so dynamic, we can think strategically when needed, but can switch into tactical mode as the inevitable fires need dousing.

Yup, we’re definitely cut from a special stone.

Perhaps we are what we think we are and have the impact that we think we have in companies.

If that is the case, then let’s look at ourselves honestly and ask:

• Why is it so hard to find a standard or generally agreed upon definition of what Software Product Management is across the industry?

• Why are there really no formalized education programs for Product Management?

• How can a 3 day training course even begin to prepare someone to be a product manager?

• Why are our blogs and books filled with an endless supply of “tips and tricks”, as if that is the route to success?

• Why do people think that a smart sales engineer will automatically make a good product manager?

• Why do so many senior managers think that hiring lots of engineers is more important than hiring a few more product managers?

• Why are so many PM consulting firms selling templates and spreadsheets that are both “comprehensive”, yet “fully-customizable” and that enable you to “increase your professionalism”? Really? Is that what will make us successful?
  

If we take a step back and look at our profession, there are many other questions like this that are left unanswered. I wrote a bit about this topic previously in Product Management Maturity and If we’re so smart.

Think I’m being hard or unreasonable? I don’t think so. I’ve been in Product Management for over 10 years and I’m not looking to jump ship yet. I want to see if we can accelerate the process of maturing this field and helping those who are looking to become product managers avoid the struggles we “veterans” have faced.

What have we done in the last 10 years to make our lot better? And I don’t just mean incrementally better. I mean significantly better.

Software Engineering has really evolved in the last decade. The latest greatest things right now seems to be Agile/Scrum methodologies and mature development management tools. Sales and marketing both have matured as well.

Certainly marketing has taken a big leap forward given the integration of the Web and. in particular, hard analytics into the marketing process. Branding, positioning and other traditional marketing activities are still important, but the potential sophistication of marketing today is an order of magnitude above where it was a decade ago.

Selling still retains a lot of it’s old characteristics. Certainly there is no electronic replacement for a good relationship with a buyer or prospect. But sales automation has improved and there are a lot of mature and time tested sales methodologies to choose from.

And then we come to product management. What have we done in the last 10 years to really improve our profession and define ourselves to those around us? Given that there still isn’t some well understood definition of what we do, I’d say we haven’t done enough.

Instead of getting all hot and heavy about the latest development methodology, let’s develop our own well defined, clearly beneficial and easily understood models for product management. No one else is going to do it for us.

And a few years from now, if I’m still writing this blog, I’d hate to have to look back at this post and say, gee, not much has changed has it.

Saeed

What’s the deal with Product Roadmaps?

As a product manager, I’m sure you’ve had to create a roadmap or two to convey future plans or, at minimum, as a sales tool so the sales people can talk somewhat convincingly about a purely hypothetical future.

Product roadmaps are meant to be a tools that are used to provide a high level view of product direction over a number of release cycles. They are used for both internal and external communication, and should present a reasonable or likely predication of the future of a product.

But in reality, roadmaps are more often aspirational rather than acheivable. What other documents do you produce the regularly require massive disclaimers and Safe Harbour clauses on the very first slide?

Roadmaps too often represent the dreams or hopes of the PM, created without needed analysis of effort and resources. It’s very easy to create a roadmap that lays out a great story, with all the good stuff people want, being delivered 9-18 months out. Seems reasonable doesn’t it. There’s a lot of stuff that can be done in a year and a half, if we start thinking and planning for it now. Correct?

Funny how those plans quickly go awry. The reality is that most product roadmaps seem to have been created over coffee in the company cafeteria. They typically show aggressive development plans and signficant deliverables over a short period of time. All of this sounds great and enables the PM to make impressive presentations to wide audiences.

And therein lies the problem. While the individual has to hold some responsibility, the majority of the problem lies with PowerPoint, the preferred medium for describing roadmaps. Yes, you heard it here:

This medium corrupts the message!

People want to see the roadmap on a single slide. Now how much information can one actually put on a single slide and make it look “great” and “worth the wait”? If each release is about 6 months, then you’re likely to have about 2 years worth of roadmap projections displayed on that one slide. It’s all great, until someone tries to define what Dev has to do to build and deliver to the roadmap. At that point, the roadmap might as well be tissue paper, as it has little substance.

Now, we all know that well analysed development plans for a single release often significantly underestimate the amount of work and time needed to complete. We all know it, because we’ve all experienced it first hand in at least one company where we worked. And if that is the case, then how would it be possible that a 2 year roadmap built on high level bullets with little detailed effort and scoping analysis could actually bear any semblance to reality.

At one company where I worked, the PM team was well aware of this problem, and if a capability was “on the roadmap” (nudge nudge, wink wink), it meant it had an almost 0% chance of being released in the next 24 months.

Sales people want product roadmaps to be set in stone once defined. This helps them make firm commitments to customers who need some pending functionality. On the other hand, sales people also want PMs and Dev to react quickly when a “big deal” is on the table and closing it requires “a few enhancements” to the product.

In the end, the roadmap is simply one of several documents that can be used to communicate future plans to potential customers. For consumer software, this is rarely an issue. But for B2B or Enterprise Software, the best thing to do is define a clear and regular method of communicating the roadmap and any changes in it to key members of the sales and marketing teams, to ensure they can position and communicate the future plans to their audiences as confidently as possible.

Saeed

Xobni: Cleaning up email

If this product works as advertised, it will help a lot of us. Email has become the unstructured data repository from hell. I read somewhere that up to 80% of corporate data sits in email somewhere. Filing email into folders is fine for some people, but most of us are not that structured, and even if we are that structured, it’s not always clear where an email should be kept for reference sake.

Xobni is trying to help change this. Check it out by clicking the badge below (or this link), and let me know what you think. I’m going to experiment with it as well.

Alan

RACI

Paul over at Product Beautiful had a great post about RACI- a way to breakdown deliverables by the people who are:

• Responsible
• Accountable
• Consulted
• Informed

for each deliverable. It’s very similar to Saeed’s concept of the Information Supply Chain except that it just focuses on the people and not when or how the activities take place. But as a simple planning tool it’s a great, clear approach.

What’s the deal with Personas?

The CrankyPM recently posted a good little rant on personas. It’s drawn some interesting comments from both sides of the persona camp (PCamp? ). BTW, I’m totally jealous as she snagged a great title — Persona non grata — for her post.

I’ve been incubating the following persona related post for a while, and thought now a good time as ever to finish and post it.

There’s been a fair bit of writing related to personas as a tool for better understanding users and their requirements. Adele Revella has The Buyer Persona blog, and Bonnie Rind has her Product Personas blog. And of course, the accredited father of the persona concept for product design is Alan Cooper. Cooper’s firm has a number of persona related articles on their site. Perfecting your Personas by Kim Goodwin provides a good overview for those who are interested in understanding the basics.

She starts:

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype.

This makes complete sense and whether one is explicitly familiar with personas or not, it’s what most Product Managers tend to do, some better than others.

Later Kim writes:

There is seldom a one-to-one correlation between personas and job descriptions. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs.

Thus for a single job — say an administrator — there could be personas representing new administrators who need lots of prompting, and experienced administrators who prefer command lines and know exactly what they need to do. Again, not much to debate here.

Later on Kim writes:

You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don’t just say he’s incredibly busy; instead, say there’s a sandwich on his desk that he’s been trying to find time to eat for three hours.

Now this is where things get interesting, and this is the issue that Cranky fixates on in her post. And to be honest, it’s really hard to disagree with Cranky. Imagine the look on a bunch of developers faces as you start laying out the persona, describe their environment, their goals, their workflow, and the fact that a sandwich has been sitting on their desk for 3 hours.

Might as well stamp the words — Marketing dweeb — across your forehead and then tell them you’re going to get a soy latte at the brasserie. First of all, I’ve yet to meet a development team that cares about these kinds of details. They don’t want to know that Albert, the community college grad who provides DB2 database administration support likes to watch Ren and Stimpy videos while he waits for nightly database backups to run.

They also don’t want to know that Sachiko, the business analyst, has an MBA from a second-tier Midwestern university, is planning the details of her upcoming marriage, and thus doesn’t have time to conduct proper and formal analyses for the new CRM system that is needed.

These are all completely unnecessary details in the B2B context. For consumer software or products, these details may be very important.

A while back, I worked on a new Administration Console for an enterprise middleware product. The product itself was in widespread use, but there was a real push to make it “enterprise ready”, which meant that things like security and role based permissions were important.

The developers spoke about the target user — “the administrator” — in very vague terms. There was also confusion around the fact that some users of the product could act as both administrators and operators depending on the circumstances.

We needed clarity on this and a way to distinguish who did what, when and why with the product, and who the target would be for the new Administration Console. So, we decided to talk to customers to get some raw data. After a number of customer visits and calls, we determined the following:

• There were four major “administrator” roles within our customer base
  • Network Administrators
  • Infrastructure Administrators
  • Application Administrators
  • Operations Administrator

• These four roles were generally consistent across customers, though responsibilities crossed over between roles in different customers
• Administration teams were structured very differently across organizations
  • Some customers had administration teams with global responsibilities
  • Others had teams with specific geographic focus (e.g. Americas, APAC, EMEA)
  • Others had teams responsible for specific applications

From these and other findings, we came up with specific definitions of the roles. Here’s the definition of the Infrastructure Administrator which we decided was the target user for our Administration Console.

An infrastructure administrator is concerned with a specific set of hardware and software running on that hardware. This set of hardware/software is usually domain specific. I.e. it is assocated with a particular enterprise application, such as Siebel, PeopleSoft, an external web application or some other system.

The infrastructure administrator’s job is to ensure that the particular hardware and services, particularly the services, they are responsible for are operating efficiently and that any general maintenance, such as application data backups, server shutdowns etc. are managed in an efficient way.

In the context of our product, an infrastructure administrator is responsible for starting/stopping repositories, configuring servers, performing repository backups etc. In most cases, but particularly with small to medium installations, the infrastructure administrator also handles inter-repository migration of metadata. i.e. they do the deployment from development to test, and test to production.The infrastructure administrator is the primary user of the Administration Console, though from our discussions it is clear that they do not need to use it everyday.

The developers really understood this description. We had similar ones for the other three types of administrators, and throughout the development of the Administration Console, we regularly referred to these roles, their descriptions and other findings from our research when questions arose as to what should or shouldn’t be part of the console. Notice there is no mention of personalities, habits, level of disorganization on someone’s desk or anything that detracts from the role and it’s focus.

So, what’s deal with Personas? Technically nothing, unless you insist on using them with engineers or other people who just couldn’t give a damn about all that extraneous “marketing fluff”. A big part of Product Management is communication, and speaking in the language of others. If engineers don’t “grok” personas, don’t force them down their throats.

Saeed

Product Manager vs. Product Management (part 6)

In part 5, I showed how you can begin to decompose the areas where teams, particularly Product Management, provide key deliverables to other teams. Here’s what the heat map looked like for Product Management across the stages of the development cycle.

(click to enlarge)

For each colored element in the heat map, a list of deliverables and dependencies for that team at that stage of the cycle must be defined.

One important note here. Even though the chart above lists discrete stages in the development cycle, the stages can and likely will overlap in time. For example, Pre-Beta, Beta and Post-Beta all occur during the Product Development stage. And the Sustaining column is a set of ongoing deliverables that occur throughout all of the other stages and feed into stages such as Product Definition.

So, if one were to take a stab at listing the key deliverables at each stage of the development cycle, it could look something like this.

(click to enlarge)

I say “could look something like”, because it will vary somewhat from company to company, and possibly even from product to product. For example, A hardware product, e.g. an appliance, will have different deliverables at certain stages than a client-based software application. And the client-based software application may have different deliverables from a hosted SaaS application. Having said that, the stages and deliverables listed in the chart are relatively generic and should apply in many circumstances. And finally, some of the items may better fit in other columns depending on the company and the specifics of the situation. e.g. demo creation may take place later in the development cycle, closer to launch, may not even be a Product Management deliverable in certain companies, or may not even be needed at all!

In the context of the Information Supply Chain, when thinking of deliverables, there are upstream dependencies and downstream dependents. Upstream dependencies are any deliverables that must first be completed by yourself or others, in order for you to create your deliverable. For example, a good Product Requirements Document (PRD) might depend on the existence of a Market Requirements Document (PRD). Thus the MRD is an upstream dependency of PRD. Conversely, for every deliverable, the downstream dependents of the deliverable must be identified and documented. e.g. For a PRD, the downstream dependencies can include Functional and Design Specifications created by Engineering and Product Description and Overviews created by Product Marketing.

Now let’s look at the first column and drill down some more.

It has three potential deliverables:

• Statements of Direction
• Market Requirements Document
• Product Roadmap

Each of these needs to be defined and the dependencies (upstream and downstream) need to be identified. Luckily for Product Management, there are very few upstream dependencies in this case. Here’s the text for the Statements of Direction:

Statements of Direction (SODs) These are high level strategic documents, describing a number of characteristics about a new or needed technology or functional area to be added to the product. A typical SOD should be about 2-3 pages in length maximum . i.e. not lengthy.

SODs are typically theme based documents (e.g XML, Web Services, 64-bit Computing etc.) that describe major milestones needed across releases for given themes. A good SOD should include an “elevator pitch” describing the theme, a market or technology overview, including competitive info and market risk if necessary, the case for change and benefits for implementing the change, and a summary roadmap for the theme.

Internal Consumers: Product Management, Product Strategy, Development, Product Marketing External Consumers: Strategic Customers and Partners

Downstream Dependents: A Statement of Direction provides the necessary input for Product Marketing to create a “Point of View” (POV) document. Multiple Statements of Direction, defining objectives for multiple themes provide key input for Product Roadmaps

NOTE: A POV is an external facing document that can be used by Sales to convey product intent on a particular theme to customers/prospects/partners without revealing internally sensitive information

As you can see, this is a clear and succinct definition that describes the intent, general contents and consumers of the document. In this example I’ve added the NOTE to show an explicit downstream dependency of a Statement of Direction.

Here’s the definition of the Market Requirements Document. This should be familiar to most, if not all of you.

Market Requirements Document (MRD) MRDs are quite commonly produced by Product Management and/or Product Marketing. More applicable to new products, MRDs, like SODs, are strategic documents, but typically provide much more detail about the market dynamics and market sizing, the competitive environment, the business case for developing the new product as well as likely go to market strategy options.

In short, the rationale for a new product is thought through and documented. Should the internal or external environment change, the MRD can be reviewed, updated and then reassessed to see if the new product is still justified, or what needs to be changed from a business perspective to continue investment in the new product.

Internal Consumers: Product Management, Product Marketing, Product Strategy and Senior Management. External Consumers: None

Downstream Dependents: Product Requirements Document, Positioning Documents Upstream Dependencies: None

And finally the Product Roadmap:

Product Roadmap Product roadmaps are important tools in many sales situations. Prospects, customers and partners want to know that the vendor has a solid future plan that covers key areas of concern or need.

A roadmap should provide a high level view of key product releases and major functionality over time. Most roadmaps cover 12 to 18 month time frames and at least one major version release into the future. Roadmaps are typically communicated to external parties by Product Managers, Sr. Management and senior members of the sales and sales engineering team. Keep in mind that roadmaps represent a projection of plans into the future, and while one can strive to be honest about those plans, roadmaps do not in any way indicate commitments to deliver any specific functionality in any specific release or by any particular date. This must be conveyed explicitly to those who receive roadmap information

Internal Consumers: Product Management, Senior Management, Sr. Sales and Sales Engineering staff. Others on an as needed basis. External Consumers: Customer, Partners, Prospects

Downstream Dependents: Product Requirements Documents Upstream Dependencies: Statements of Direction

So there you have it. The first column of the Deliverables table is now defined. The task for you is to go and try this on your own for other items in the table. Pick a couple of them and work on the definition, the consumers and the downstream and upstream dependencies. Feel free to to post some of them in comments on contact me if you have some questions.

It’s important to work through this exercise within your own company. Explicitly understanding not only what you need to do, but who you depend on and who depends on you across the stages of the development cycle is a very important exercise. I can almost guarantee that you will find a few surprises and challenges as you work through the process.

Saeed

Related Posts
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)

Product Manager vs. Product Management (part 5)

In part 4, I discussed processes, and talked about loosely-coupled and tightly-coupled processes. The reason I wanted to introduce those is because when I talk about understanding the Information Supply Chain and defining key Product Management tasks, it is in the context of supporting loosely and tightly coupled processes.

First, let’s define “Supply Chain”

A coordinated system of organizations, people, activities, information and resources involved in moving a product or service in physical or virtual manner from supplier to customer.

This is roughly what Wikipedia says at the beginning of it’s page on the topic. The page needs work, but I like the definition. Note the terms “coordinated”, “people”, “activities” and of course “information”. A supply chain can be a complex entity, and certainly in the physical world, it involves moving physical goods (raw materials, parts, finished products) from place to place, to those who need it, as they need it (just-in-time delivery).

In the software world, and particularly in the context of the software development process, the focus is on delivering high quality information to those who need it as (or before) they the need it. One nice thing about information is that there are no inventory or warehouse costs for storing a document that is delivered early. Along with time, information quality is also important. A good requirements document delivered on time is much better than a poor document delivered early.

If you take a step back and look at the product development process, it is fundamentally about information flow and optimizing that flow. Deliver requirements late or poor requirements on time, and extra work must be done to accommodate for that. If requirements are not clear and precise, it can impact the amount of testing that must be done as the implementation of those unclear requirements may be sub-optimal.

Beyond the actual development process, if the requirements aren’t clear or, if they don’t correctly address market needs, then marketing and sales have to do extra work to achieve their goals. I’m not saying that everything is the result of faulty requirements, but simply illustrating the downstream impact of a single deliverable — the PRD. The same is true for every other information transaction that occurs. If the communication is not clear, or delivered in a “language” or with content unsuitable for the target audience, friction ensues.

We’re all familiar with the famous “tire swing” cartoon, which very succinctly illustrates this point.

(click to enlarge)

The software development process is complex, risky and full of unknowns. It’s really not like building a house, for example, where structural strengths of the materials are well known, the design is well understood, the land around it is suitable, and it’s very unlikely that every year, the ground it’s built on changes consistency. In general, it’s rare that the assumptions that were made in building the house are no longer valid. This is what happens to houses when that occurs.

(click to enlarge)

When this happens to a house, it’s time to get a new house. When this happens in the software world, people call support and expect someone to fix it! But I digress.

Given the risks in the product development process, it is important to understand who needs what information, when they need it, and for what purpose. One can then identify what role each team, including product management plays in this information supply chain, and what outputs are needed. I wrote about this topic a bit in a previous post, but its worth repeating here as it is critical to getting down to the definitions of deliverables that are the ultimate goal of this exercise.

If one were to look at all stages of the product development process, and identify all the parties (internal and external) that were involved at each stage, and map the intensity of their activities during those stages, you’d end up with a diagram that looks something like (but not necessarily like) this.

(click to enlarge)

This is a very simple heat map showing (on a scale from 1 to 3), the level of intensity of involvement of each group (shown on the left hand side) during each stage in the development process, from research, through development and out into launch etc.

Looking at the heat map, it’s clear that most of the intensity — and thus activity — is on the right hand side, i.e. the latter stages of product development, launch and release. The majority of the activity on the left hand side is in the top left, and related to product strategy, product management and product development teams.

So the question is, how do you optimally get from the left hand side to the right hand side? Or put another way, what information must flow between the groups, across the stages to ensure that the activities on the right hand side can be performed optimally?

To answer that for the whole diagram would not only be a huge task, but somewhat off topic. This blog is called On Product Management and not On What Everyone Should be Doing in my Software Company.

So, let’s look at the Product Management line only. Aside from making the task at hand simpler, this is also a good simplifying assumption for the whole supply chain process. The impact of product management on downstream activities is clear. So, if you can get that right, you’ve addressed a big part of the problem of optimizing downstream activities of other teams.

(click to enlarge)

The Product Management team is heavily involved from the early stages right through until almost the end where the intensity of involvement in a release drops off after the release is out in the market. There is still some activity of course, but in reality, when the product is launched, other teams such as Sales and Support are heavily focused on it, and Product Management focuses on upcoming releases.

The task now is to look at each stage, and list out the deliverables that must be created so that other teams can do their jobs in latter stages. Keep in mind that this is not a list of activities at a given stage, such as talking to customers, analyst meetings, win/loss analyses etc, but a list of deliverables that will be passed on down through to other teams so they can complete their work.

For example, a PRD may be the result of things like customer visits, analyst meetings and win/loss analyses, but the deliverable to the development team is what is important in the Information Supply Chain, because without it, they can’t do their job. How you created it is less important (to them). The assumption is, you are doing what you need to do to deliver the right requirements to them.

So, a bit of homework.

Think about your company, and what deliverables you need to provide to other teams at each stage of the development process. Also think about what others may need to deliver to you so you can get your job done as well.

In the next post, I’ll drill down even further into the specifics of deliverables at each stage and provide examples to help you define a Product Management Information Supply Chain for your company.

Saeed

Related Posts
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 6)

Product Manager vs. Product Management (part 4)

I received a number of requests for the “20 page document” mentioned in part 3 of this series, that defines the activities in the Product Management Deliverables grid. (see below)

(click to enlarge)

After some thought, I’ve decided not to simply post that document in the blog or email it out to people. It is a document that represents the implementation of the product management function at a particular company where I used to work. Looking through the document, it would take me a couple of hours to clean it up, remove any company specific content and make it presentable to a general audience.

While I could do that, I’ve decided to share parts of the document, and provide all readers with enough detail that should enable you to create a similar document particular to the Product Management function in your company. i.e. teach you to fish vs. give you a fish.

For starters, here’s a portion of the table of contents of the document.

(click to enlarge)

Processes
I begin by discussing the concept of tightly-coupled and loosely-coupled processes.

Tightly-coupled processes are the type one typically associates with product development; ones with numerous dependent tasks, specific schedules, and resource allocations requiring ongoing status meetings to coordinate and execute. Examples of tightly-coupled processes include software development schedules and product launch activities.

Loosely-coupled processes are very different from tightly-coupled ones. In a loosely-coupled process, individual tasks are not as temporally dependent on one another as in tightly-coupled processes. Yes, the linkages and connections are there between tasks, but direct blocking issues are less frequent, and less ongoing coordination is needed than with tightly-coupled processes. But, this does not mean there aren’t dependencies. Think about how Product Management and Product Marketing must work together during a product release. Each have their own activities and deliverables, but there is also a dependency between them. The same is strue for how Product Marketing and Sales must work together.

A loosely-coupled process may consist of multiple teams of people working mostly independently on various tasks or projects. In fact, in many cases, a loosely-coupled process may consist of a number of individual tightly-coupled processes working more or less in parallel towards the same goal.

Most companies are well versed in managing and completing tightly-coupled processes. This is because the individual tasks can be clearly defined, dependencies identified, and significant ambiguity removed. There is also significant transparency into the activities of other teams. This transparency is a necessity when working in tightly coupled groups.

But, when it comes to loosely-coupled processes, companies have a lot of trouble managing them. The reasons for this are many, but in general it is because the interfaces between loosely coupled processes are poorly defined, the groups may have divergent short term goals, or that specific owners with both the responsibility and authority to ensure tasks crossover smoothly are not present. There is also little transparency in the tasks across groups, so the dependencies of tasks across groups is harder to track. In reality only the interface points, i.e. the truly dependent deliverables between the groups need to be identified and tracked.

Within the product development process, Product Management plays a key role in delivering (producing) key information to other teams (to consume) so those loosely coupled processes execute effectively.

Thus, clearly defining each Product Management deliverable , when it needs to be delivered, what it needs to contain, and who will use (consume) that deliverable is the first step in creating an effective product management process.

In my next installment, I’ll continue describing the contents of the document. I’ll introduce the concept of an Information Supply Chain, and how that drives the definition of the Product Management function.

Saeed

P.S. If you want to “read ahead”, watch or listen to this webinar I gave in 2007 about the Information Supply Chain.

Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)

Product Manager vs. Product Management (part 3)

How important a role does Product Management play in your company?

Is it truly a strategic role, or is that just what is written in the job descriptions when hiring PMs?

Who sits at the table?
Does Product Management report directly up to the CEO, or does it report through Marketing or Engineering, or heaven forbid, up through Sales. Not that I have anything against the Sales orgs in companies, but if Product Management is reporting up through Sales, the company doesn’t understand the role or the benefits Product Management can provide.

I view Product Management as a key function in a company that should have VP representation at the Sr. Management level. i.e. Product Management should be on par with Sales, Marketing, Engineering, Finance etc. and should not report up through any of them. If that is not the case, then that means that the company views Product Management as subordinate to these other groups and not worthy of “a seat at the table”.

It means that the influence Product Management will have will be subordinate to the influence these other groups have. For example, if Product Management is part of Marketing, and Marketing consists of Corporate Marketing, Product Marketing, Field Marketing and Product Management, guess how much focus and attention Product Management will have from the VP of Marketing, let alone the Sr. Management team?

Are PM roles defined clearly?
Second, it’s very important to clearly define the duties and responsibilities of Product Management and demarcate them from analogous duties that other team may have.

For example, when talking about Competitive Analysis, one must distinguish between the types of competitive analysis that, for example, Product Managers need to help define future releases of products, and the type sales teams need to compete on competitive deals. The end audience for those analyses is important in deciding who will create the particular outputs.

Sales teams need competitive information so they can position products clearly and respond to prospect questions or objections. Sales people may need high level “kill sheets” that list the key benefits and strengths of their offerings, and the key weaknesses and threats of the competition. Sales Engineers working with Sales Managers may need more detailed technical feature/functionality information. This is typically the job of Product Marketing.

Product Managers need very specific information about competitor’s strategic direction (and roadmap if possible), product functionality, limits or shortcomings, as well as key differentiators. i.e. the gaps between what the competitors does (or will do) and what the PMs own product(s) do and will do.

It is based on this type of detailed information that PMs can make the appropriate decisions on how to invest the time and efforts of the development teams to produce future releases of product. But, this kind of information is, in itself, not useful for sales teams.

Now, who can provide this kind of information for Product Management? Likely only other members of the Product Management team — perhaps Technical Product Managers, or Solution Architects or Technical Competitive Analysts — because other groups, such as Product Marketing, or Sales Engineering don’t have a vested interest in doing this work. They have other goals and objectives to focus on.

How to define the roles well?
The question then is how can the roles of the Product Management function be defined for maximum efficiency and benefit? Take a look at the following two diagrams. The first is a relatively well-known Pragmatic Framework diagram from the people at Pragmatic Marketing.

(click to enlarge)

This diagram defines a number of possible activities ranging from Strategic to Tactical, in various categories such as Market Analysis, Qualitative Analysis, Product Planning, Sales Readiness that various people must complete during the product definition, development and launch cycles. Notice that it does not explicitly define the time frames in which these activities must be enacted, nor does it provide any specific order in which these activities must be completed. It is a generic framework diagram that can be used as a basis for defining the Product Management function in a company.

The second is a not so well-known diagram by yours truly.

(click to enlarge)

This diagram is almost orthogonal to the Pragmatic diagram. It lists specific deliverables that the Product Management function must deliver on during the product definition, development and launch cycles. It is categorized by stages in the development process and not by functional area ranging from strategic to tactical. It is, in fact, a specific implementation of the above Pragmatic framework diagram, tailored to a particular company’s need. Your company may have different needs and thus a somewhat different diagram.

This diagram, backed up by a roughly 20 page document describing each of the deliverables in the grid, down to who participates in completing them and who accepts the deliverables that are generated at each cell in the grid, describes very precisely what Product Management does, and equally importantly, what Product Management doesn’t do. Left out of this diagram are specific activities such as working with sales to help close deals or even, for that matter, visiting customers/prospects. Those are fundamental things that must be done as part of the job and feed into the deliverables listed in the diagram.

So, why go through the exercise of creating the diagrams and supporting definition documents? Well, if you truly want to build a Product Management function in your company then the first thing you need to do is clearly define what that function is responsible for. By defining it this way — what needs to be delivered when, to whom and by whom — the focus is placed on the outputs and those dependent on the outputs (the what) as opposed to the specific tasks that need to be completed (the how). Put another way — the people who depend on Product Management to do their jobs know well in advance, what to expect and when to expect it, without placing specific restrictions on how those deliverables must be completed. That is left to Product Management to decide.

Sounds like a model of efficiency to me. And isn’t that what you’d expect from anyone who has a seat at the Sr. Management table?

Saeed

Related Articles
Product Manager vs. Product Management (Part 1)
Product Manager vs. Product Management (Part 2)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)

Question for you: Corporate Blogs

I mentioned earlier that my company has a blog. So, what’s new about that? Well, like many things, there are good blogs, bad blogs, and good and bad corporate blogs. I dislike blogs that are blatant marketing pitches, and it’s clear that readers don’t like them much either. One of my recent entries was picked up by Jesse Wilkins, where he gave a very nice compliment, namely that “I can recommend it comfortably as a good example of how to do a vendor blog”. Thanks Jesse!

Blogging for my company has got me thinking, and Jesse’s comment focused it for me: what makes a good “vendor blog”? In a future post I would like to write about corporate blogging from the perspective of product management and marketing. But who better to ask about this topic than you, dear reader?

Here are my questions for you:

1. Are you involved in your own company’s blog? If so, drop me a note and tell me a little more.
   1. What is the purpose of your blog?
   2. What works for you and your blog?
   3. How do you measure success?
   4. How do you avoid irregular posting schedules
   5. How do you deal with company confidentiality vs. transparency, and … here’s a hot issue, how do you share openly while staying “on message”?
2. Do you read any blogs regularly? If so, what are they? What do you like about them? Are there any corporate blogs on the list?
3. Any war stories about publishing your content would be most helpful.

I hope to hear from you. You can email me here: Alan Armstrong.