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)