The main thing is keeping the main thing the main thing

A mentor of mine used to repeat this line fairly often to me: The main thing is keeping the main thing the main thing. The quote comes originally from Stephen Covey.

Like many of Covey’s aphorisms, this one sounds simple, yet is hard to put into practice.

There are (at least) two reasons for this:

1. You don’t know what your main thing is
2. Other people drag you in to their main thing

The main thing for Product Management

Product Managers can find it difficult to define their main thing. Is there only one? Some PMs focus on development, and view product requirements as their main thing. Others focus on sales, and view sales support as theirs.

I don’t subscribe to either of these extremes. Yes, at times, we must cater to one department or the other.

But the main thing for a Product Manager on my team breaks down into three categories. It’s my article, so I get to name three main things:

1. Know thy business: Attending to the health of the product line as a business.
2. Know thy buyer: Understanding the experience, context, and needs of buyers before, during, and after a purchase.
3. Now Lead: You must enable and empower others in the company to carry out the detailed tasks.

Yes, R&D needs requirements, and yes, of course, sales people need training. And quite often, you will be the one to provide both.

But if you are doing either of these and cannot tell me how they connect to the main things, we will have a problem. And if others won’t follow your lead, you’re doomed.

Things that distract you from the main things

The problem with the definition above is its breadth. To truly attend to the business and the buyers is a huge job and can lead to burn-out. What’s worse, it you spread yourself too thinly, you will fail at everything rather than succeeding at something.

It is crucial, then, that you circumscribe your activities. Put boundaries around what you can do. There are two ways to get distracted:

1. Corporate work:  Executive off-sites, special projects for the CEO, portfolio reviews, corporate budget meetings.
2. Line-work: Working the booth at a trade-show, writing copy, detailed requirements or product design, sales calls, product demos.

Which one of these traps do you or your staff fall into? I think it must depend on personality. Some people are more naturally drawn to one or the other.

Keeping the main thing the main thing

Fixing this problem is not easy. Product Management is by its nature a cross-functional job that almost never ends. It will never be easy, but some tips might help:

1. You need support: You need marcom to write copy. You need creative support. You need a product designer to create detailed requirements. You need a development manager to understand the business to assist you with feature triage.
2. Let them do their jobs: Perhaps more than anything, you need to let others do their job. You need to lead them, empower them, but stop short of doing their job. You must to allow others to succeed or fail under their own steam. You might imagine that you can do it better than they can do it. But if you do it, you’re missing the main thing.
3. Narrow the concept of your job: Few companies staff to do Product Management properly. Saeed has argued in the past that you can never have too many product managers. 🙂  And while this may be true in theory, few companies invest sufficiently in product management. If this is the case for you, figure out the one or two areas where you need to make an impact. It may be in the product, but it may equally be in sales. It may switch from time to time depending on the cycle you are in. This is very difficult, but try planning things out with your boss.
4. Organize and staff for effective Product Management: If you are in a position of leadership, your main thing may be to bring the company into line organizationally. To be successful, product management needs design execution, time and money to study buyers, and support from the rest of the organization.

Homework assignment
Questions to consider for you, your team, and individuals on your team:

1. What is your main thing?
2. How does your main thing align with my suggestions? (Know the business, Know the buyer, Now Lead.)
3. What kind of distractions are you prone to? (Corporate work? Line work?) List them. Talk them over with your staff or your management. Make these a point of development for each member of your staff and for yourself.
4. Do you need to narrow your job? If so, what tactics will you use?
5. How can you get buy-in to focus on your main thing?

Final remarks
The trouble with the main thing, as with so many other of Stephen Covey’s ideas, is that they require you to ignore, or de-prioritize tasks that would normally give you great satisfaction or immediate praise. You may need to recuse yourself from some Executive Work that strokes your ego. Or you may need to put up with product design that is lower than your own standard.

Whatever your temptation may be, start by knowing that you have it. Decide when to wade in to a distraction … sometimes you must.

Perhaps there is one more main thing: Know thyself. If you know your own temptations, you can start to overcome them.

Good luck. Let me know how it goes.

– Alan

Reference customers for YOU, Inc.

Do you have reference customers?

Think about that question again. I’m not asking about your company. I’m asking about you personally. The next time you are interviewing for a job, I want you to be able to say that your references are at Fortune 500 companies, not just previous employers.

Yes, it is important that previous employers will refer you. But think how valuable it would be to say in your next interviews – right out of the gate – that your references are at Wells Fargo. Or Bank of America. Or AOL. Or Facebook. Or … name your customer.

Imagine that you are hiring, and you interview 5 candidates from a list of 25 resumes. Three of them look about the same, two are marginal but you interview them anyway. In the interview, one of the candidate says that she has 3 customer references. Which person would you hire? The one who talks a good game, or the one with customer references?

Make it a priority to develop reference customers for you personally. Introduce yourself. Make a difference for them. Cultivate the contact. The difference for you at your next job change will be incredible.

Alan

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

The rest of the series
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 6)

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 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

The rest of the series
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 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.

The rest of the series
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 6)

Product Manager vs. Product Management (part 3)

NOTE – THIS BLOG HAS MOVED You can see the new version of this article at the following URL: http://onproductmanagement.net/2007/12/18/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

The rest of the series
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 6)

Product Manager vs. Product Management (part 2)

NOTE – THIS BLOG HAS MOVED You can see the new version of this article at the following URL: http://onproductmanagement.net/2007/11/12/product-manager-vs-product-management-part-2/

In part 1 of this series, I talked about the lack of maturity in the product management role in technology companies. Computer technology and software themselves are rather immature, and given the rate of change in the computer technology industry, that immaturity will be here for some time.

It took over 80 years — from the introduction of Ford’s Model T in 1908 — for the automobile market to reach a level of what I would call maturity. And by maturity I mean the ability for manufacturers to consistently produce high-quality cars and trucks that consistently deliver value and address market needs. OK, not all car companies do this, 🙂 but companies like Honda and Toyota certainly do and they have proven that it is possible to not only systematically do this, but to do it even in the face of severe economic and political obstacles.

I recently got rid of my 12 year old Honda Civic. We bought it back in 1995 just after we had our first baby. Later, when we bought a minivan (Honda Odyssey), the Civic became my daily commuter car.

I drove that car every day to work and back for about 10 of the 12 years: on average about 70 km per day. I would have kept driving it, except that a few weeks ago, someone drove into the side of my car as I was driving home. It was dark, and raining, and there was heavy traffic on the road. Luckily no one was seriously injured. After over 220,000 km, I had to turn in the keys on the Civic.

Recently I picked up my replacement car. It’s a great little car and driving it to work is easy. And guess what, it’s a 2003 Honda Civic. Yes, I went out and bought a newer version of the same car. And why wouldn’t I? My previous Civic worked, plain and simple. It didn’t require special maintenance of any kind. I’m not a great car owner to be honest. I’m not always timely with my oil changes. I don’t check the tire pressure as often as I should. But my first Civic kept on working over the 12 years and had someone not run into me, I wouldn’t have gotten rid of it.

And coincidentally last month, Consumer Reports named several Honda and Toyota models as “Good Bets” for vehicles to last for 200,000 miles (320,000 km). Funny how no American makers made the list.

And why would they. The Japanese auto makers have transformed the automobile industry in the last 35 years. From a humble start selling low priced, low quality cars, both Honda and Toyota have embraced continuous improvement in all aspects of their design and manufacturing process. Numerous books have been written about these companies particularly Toyota:

So what does this have to do with software product management? Everything.

Product management must keep the process of continuous improvement in mind at all times. This not only means continuous improvement in the products delivered to the market, but continuous improvement in the processes, both internal and external, that deliver those products to market.

This is where the function of Product Management must be considered as opposed to the role of Product Manager.

Many companies mistake the two as being the same and that is a source of problems. Consider the analogy of the function of Engineering and the role of a software engineer. The former includes the latter, but there are other roles in engineering, such as architect, development lead, interaction designer, tester etc. that help compose the role of Engineering in the company. Each of these roles plays a well defined part in ensuring the output of Engineering meets demands and expectations. The same is true for the function of Product Management.

Software Product Management must focus on optimizing the business side of software, ensuring that the R&D investments made in developing product are the best ones given available information and that the processes used to roll out and take products to market are working to maximize the return on those investments.

Granted, this is not how all software companies view Product Management, but to be honest, they should. Because in reality, if Product Managers aren’t doing this then who is? Finance? Marketing? Sales? Sr. Management? Sr. Management is responsible for the overall business, and in small, single product companies, that may overlap completely with the business role of the PM. But in any company that has multiple products, Product Management must be focused on optimizing the business of the products and product lines they manage.

Now I’m not saying that Product Management should ignore the technology. No, that is a key aspect that needs to be addressed, but one shouldn’t assume that the same Product Manager, who is looking out for the overall strategy and business objectives of the product or product line can also focus on the technical details of the product as well.

In the next article, I’ll delve into how to decompose roles in the Product Management function to maximize the output of the team.

Saeed

The rest of the series
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 6)

Product Manager vs. Product Management (part 1)

NOTE – THIS BLOG HAS MOVED You can see the new version of this article at the following URL: http://onproductmanagement.net/2007/09/20/product-manager-vs-product-management-part-1/

I recently finished a series of articles on being a Great Product Manager. I want to switch gears a bit and spend some time talking about the function of Product Management in software companies. As we know, product managers and product management are not isolated to software companies, but the role of product management in software companies is different from the role of product (or brand) management in other domains, such as the financial sector or Consumer Packaged Goods (CPG) firms.

For example:

• How many new “features” does a “release” of a new shampoo have?
• How much time does the brand manager spend with the chemists working on that new shampoo formulation during the “release cycle”?
• How much discussion is needed on how the consumer will actually use the shampoo?
• Are whitepapers and product demos that important for shampoo?

This is not to belittle brand management in CPG, but simply to give a few examples of how issues in CPG product management may be different than those in software product management.

One nice thing about CPG Product Management is that it is fairly well defined. For CPG, Product Management is, without question, a marketing function. CPG Product Managers need to be business focussed and have a keen understanding of media and web marketing, demographics, finance and analytics. They need to be able to grasp the differences in various global markets, and be able to market global brands locally, as well as create local brands and products as needed in specific markets.

The 4 P’s (product, place, price, promotion) are fundamental to them. And, with the web growing ever omnipresent in our lives, and the emergence of new technologies allowing customers and companies to communicate more intimately with each other, terms like interaction, interruption and mass-customization are heard quite frequently.

Now compare this to Product Management in most software companies. Honestly, how many software product managers could list the 4 P’s, let alone talk confidently about the dynamics of international markets and how they impact their software products?

Full disclosure: I always list “Position” as one of the P’s (product, position, price, promotion), even though it is not. I really think it should be! Also, while I have been the PM of products that have had world-wide distribution including full localization into languages such as Japanese, French and Korean, I really had little insight into the dynamics of those markets. For the most part, beyond the specific localization, those markets received exactly the same functionality as every other geography, and it was up to local partners and distributors to market the product in the ways they saw fit.

The reality is that software product management is still an immature function. Most software companies define and staff product management in a reactionary manner. Typically a product manager is hired once the founder or CTO or chief architect or other corporate thought leader reaches the limit of their abilities in defining the product, or things become so messed up in the company with a product or technology strategy, a member of the Board of Directors tells the CEO to get a Product Manager.

It really shocks me that VC’s don’t make it a funding requirement, at minimum in the series B and above rounds, that a startup must have an experienced Product Management executive on board. Think about it? These folks are in the business of investing in technology companies. Their objective is to maximize the likelihood of success for their investments. As such, why would they not view Product Management as a critical role, on the same level as Sales, Marketing and Engineering?

I recently asked a couple of VCs this question. The answers really surprised me.

One said, quite candidly, that he really didn’t understand the role of product management very well, but that he had recently learned a lot more about it via interaction with one of his portfolio companies. OK, thanks for the honest answer, but not very reassuring from my perspective.

Another said his expectation was that the founders would fill in for the PM function until such a time as it made sense to bring dedicated product management into the company. I asked the latter VC why he didn’t view product management as a critical role to fill right at the start? He said that when he makes investments, it’s fundamentally the management team, and particularly the founders that he’s investing in. Pulling in a PM who isn’t a close associate of the founders in the early stages can be disruptive to the management team.

OK, certainly a better answer, but it says a lot about software product management when those who make their living investing in software companies cannot see enough benefit in the function to have it outweigh any concerns they have about personalities and fit in the management team.

In the next post, I’ll dig deeper into the software product management function and discuss some ways to improve both the status and discipline of the role.

Saeed

The rest of the series
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 6)