10 Tips For Product Managers
Mark Hoover, President, Acuitive, Inc.

So you want to be a Product Manager in the action-packed networking industry? Or you are one  already and you want to be a better one? Gather round.  I’m going to let you in on some of the secrets of success here.  It’s taken me 22 years to write this Musing and the next one.  It’s taken me that long to see or make every error in the book, and some that have caused the book to be rewritten (I think it’s in edition # 56 now).  It will probably take me another 22 to see the errors in the advice I am about to give you here and to correct it.  So read on at your own risk.

This subject is going to be covered in two parts.  This Musing addresses tips for how to run successful product programs, over its complete life cycle.  Next month’s Musing will focus on how to strategize – i.e. how to conceive of and validate ideas that are worthy of launching a product program to delivery.

First let me say that as a Product Manager, you are responsible for the success of a product, and every aspect of your company’s execution that contributes to the success (or failure) of a product.  Of course, you control nothing and have no empowerment over anybody or anything.  But you are responsible for everything.  Pretty good job if you can get it, huh? The fact that there is a lot of competition for these “coveted” positions continues to baffle me. 

The excitement of the job is that you are in the middle of everything.  The initial product conception, the analysis of the competition, the detailed definition of the product, the pricing strategy, the creation of the outbound marketing material, the ramp up of manufacturing, the beta customer selection and relationship management, the sales training, the customer feedback, etc., etc.

The chore of the job is that you are in the middle of everything (repeat above paragraph here).  That’s as good a place to start as any.

(1) Defend Your Time

The first thing a Product Manager has to be is an excellent time manager.  As a PM, everyone is going to want a piece of you – the engineers building the product, the engineers building supporting management functions for the product, customers considering using the product, sales people who would very much like the customers to use the product, upper management who wants to know how much the business will benefit from the product, marketing who wants to develop the story of the product, manufacturing who wants to start buying parts to build the product, the documenters who would like to say something intelligent about the product, customer service who would like to judge how much more of a nightmare their lives will be when it’s their time to support the product, various training organizations, and outside people who have various motivations for wanting to know more about the product - press, analysts, your mother, and your hair stylist.

You can’t ignore any of the people above.  They are all an important part of the success equation for your product and need to be interacted with and nourished appropriately.  But, there are only 24 hours in a day.  And you need at least three for sleeping, up to three for commuting (depending on where you live), and from five minutes to an hour each day for personal grooming (depending on whether you are meeting with engineers or customers that day).  Unless you ruthlessly plan and defend your time, you’ll find that you very quickly become a re-active force rather than a pro-active force, dealing with the requests and fires of the day, of the hour, and of the moment.  Generally, when you degrade into that mode, you find that while everyone respects your work ethic and how busy you are, no one is particularly satisfied with the interaction you’ve had with their organization, and the product will suffer.

To avoid slipping into the re-active mode, I recommend that you create a personal time budget system for every day, week, and month – allocating time to other parties as appropriate for the stage the product is in.  Keep some time unbudgeted for unanticipated events.  And then track how you actually spend your time.

To implement this process, you have to be thick-skinned (which is a general requirement for being a Product Manager anyway).  People are going to have legitimate reasons for wanting a piece of your time.  But in being selfish about how you spend your time you are being unselfish -because you and only you are in the best position to know what the priorities of the moment are and who’s needs are most critical and legitimate relative to the success of the product at any particular time.

One final hint – it’s usually a good idea to service interrupts from upper management.

(2) Leverage The Time Of Others

The second thing a Product Manager has to be is an excellent program manager.  You don’t develop, test, manufacture, sell, or service the product yourself.  Others do that.  The key to success for the product is in helping all these entities perform their duties with high quality and efficiency.  Nourishing and helping them to help themselves is your main priority, and also is the best way to get leverage so that your time is stretched less thinly.

The most important factors in good program management are communication, communication, and more communication.  After the new product program has been approved, it’s a good idea to host a kick-off meeting with representatives from all the functional areas to introduce the product concept broadly.  At this meeting, you should communicate the nature of the product, the business goals of the product (why you are building it), the high level schedule, the keys to success, the relationship of this product to others that already exist in the product line, the competitive landscape, your product’s key differentiators, technical and marketing relationships that have been or will be forged related to the product, and other information of that ilk.  If possible, it’s good to have a representative from sales tell the audience why the product is going to be super sale-able.  The purpose of this meeting is to inform and to motivate.  The meeting should be upbeat and should include a beer chaser.  Most of the people invited to the meeting won’t have to execute anything related to the product immediately, but at least it gets on their radar screen and they can plan accordingly with a good backdrop of information with which to do so.

After the kick-off meeting, you’ll want to start having regular product team meetings, with representatives from all of the functional areas.  These product team meetings should track the product realization process and all high level action items and issues related to that process.  I generally don’t recommend that these meetings be used to actually discuss and close out action items and issues, unless that can be accomplished in five minutes or less. Instead, the time should be spent defining the issues so that everyone has a common understanding of what they are, and reporting on progress.  The actual progress is generally accomplished off-line from these meetings.  At these meetings you’ll also want to launch processes for getting support plans created by each functional area.  This is your best way to get leverage – by having other people tell you how they are going to support your product. Be sure to phase and time these efforts appropriately.  It usually doesn’t make sense for manufacturing to be tasked with creating the production plan early on, before the physical design of the product has commenced, the components have been selected, etc.  Premature planning can just result in churn and de-motivation.

Be sure to keep all parties in the loop on information related to the product success that may not otherwise be essential to their execution of their part of the success equation.  At every meeting, or maybe every other meeting, it’s good to devote some time to reporting to the team the results of recent meeting with customers, changes in the competitive landscape, or updates to the business plan associated with the product.  E-mails or other communications about such items between product team meetings are also a good way to keep all parties in the loop and to continually remind them about importance of your particular product program.

In the beginning of a product development process, engineering is a lot more involved than other organizations. You don’t want Marcom people, for instance, to have to sit through too many discussions about FPGA capacities, airflow requirements, development tool shortcomings, and MIB definitions.  Too much reality sucks the creative energy right out of such people.  So you’ll probably need to have engineering-only meetings far more frequently than you’ll have all-hands project team meetings.  But still, it’s generally good to get everyone together at least once a month.  Later, as the product gets closer to delivery – and it’s key that all functional areas are participating in a coherent manner, you may want to increase the frequency of these meetings.

The product team meetings don’t stop when the product gets shipped, although that is great excuse for another party, possibly with an upgrade from beer to champagne.  Just as much work happens after the product is shipped as before, although the focus shifts from development activities to sales, support, and manufacturing.  Be sure to continue to bring interesting anecdotes about the product success – customer wins, increases in the sales of other products due to the availability of your product, competitive updates, etc., to the product team meetings.  People like to be informed, and it makes them feel like part of an important entity, on a continuing basis.

(3) Engineering Can Make You Or Break You

As a Product Manager, Engineering is your most important ally.  All too often, however, I’ve observed stormy relationships between Engineering and Product Management – so deep that the product team becomes ineffective, which usually results in the wrong product being developed at the wrong time, or the project being disbanded even though it may have otherwise been profitably salvaged.  When this occurs, I always and without exception blame the Product Manager.  I say that, because even if there are many reasons on the Engineering side why the situation may exist, the Product Manager is one and Engineering is many.  Like in baseball, you can’t fire the team, so you fire the manager.

This is just one of the many unfair aspects of being a Product Manager (hey, you asked for the job, I didn’t tell you to do it).  But because of this, it’s entirely up to you to avoid or remedy such situations.  If the relationship becomes entirely untenable, then it’s up to you to go to management and get yourself re-assigned.  Maybe Engineering would enjoy some fresh PM meat.

But let’s hope it doesn’t come to that.  Here are some tips on how to work with Engineering to reduce the probability of the relationship blowing up.

•  Invite Engineering in the game early and often.  You must get help from Engineering before a product program is approved, to validate the feasibility of a product idea, to add creative energy to its definition, and to scope out the time and resources required to realize a product.  Sometimes, the product idea may come from Engineering to begin with.  Sometimes it does not but the idea needs Engineering validation both for assessing technical feasibility as well as getting the organization warmed up to the idea of supporting such a development.  No matter where the source of the idea, you need to make sure the rules of the game are well understood by all participants – the goal is not to figure out a way to get every idea approved and funded – the goal is to ensure that only the best and most profitable ideas get approved and funded.  To that end, killing a project idea is often the successful conclusion of an effort.  This is antithetic to many Engineering minds, who tend to want to plow on and bulldog through to completion anything that they get started on.  That’s a great characteristic most of the time, but not in this case.  It’s up to you to make sure that the participants approach such pre-approval processes in the proper way and stay motivated to participate in a series of them until an idea is defined and refined that is so good, it makes it through to approval and program launch.

•  Document well.  Write your MRDs, PRDs, and other documents that define the engineering requirements clearly and precisely.  Make sure these documents describe the product and programmatic requirements unambiguously.  But just as importantly, use these or other documents to precisely describe the target customers, the target customer implementation environments, the competitive landscape, interoperability requirements, cross-product requirements, overall priorities, and other “big picture” items so that Engineering can comment on and add value to the definition of the product with that information in mind.

• Baseline in phases.  A well ordered hand-off between Engineering and Product Management requires that a number of requirements-related documents be baselined and put under change control.  People often picture this as a sequential process – Product Management hands off to Engineering and then Engineering does their stuff.  But just as Engineering needs to create a cascade of increasingly detailed documents (architecture specs, high level design docs, detailed unit specs, etc.), it’s not practical to expect Product Management to provide all of the marketing detail up front as part of one lump of deliverables.  A process of baselining and re-baselining documents on a regular basis is needed, based on a good understanding of what detail is required in what areas by Engineering at any particular time to support their processes. Underlying this process must be an understanding that previous schedule and resource estimates provided by Engineering may need to be adjusted, as increasing detail is added to the requirements provided by Marketing.  So each re-baselining process should not only be a re-baselining of the requirements, but a re-baselining of the overall product realization program.

• Clearly distinguish discussion vs. decision.  Engineering management is largely a game of churn management.  The level of detail required to successfully develop a high-tech product is enormous. Anything that causes already-defined details to be re-addressed has a huge impact on project schedules.  As PM, you are bound to be the source of potential churn, because new ideas will arise with every customer meeting and competitors will continually make new challenges.  A program, once launched, can’t be so inflexible as to ignore all of this new information.  But on the other hand, if you keep changing the product definition, you never deliver the product.  Achieving the right balance between putting things in concrete and allowing things to shift is one of your most difficult and important roles.  But, even if you achieve the right balance in terms of the decisions that are made, you can still screw up the product program if you don’t manage the process of getting to those decisions properly.  One thing that destroys development programs more than anything else is confusion about discussion vs. decision.  If you have a meeting with several engineers in it to discuss the possible impact of a change in the requirements, you better make sure they leave the room absolutely clear whether this was just a discussion, to be ignored for now, or a decision to be implemented on.  The slightest possibility of misunderstanding about this will come up to bite you big time some time in the future when Engineer A says “I thought we decided to change X,” and Engineer B says “huh?” You must make sure that discussion is clearly separated from decision.  The easiest way to do this is to have an over-riding document review/baseline process that is never abrogated.  That way, discussion can clearly be identified when the team sees it as a proposed change to an existing document and decision can clearly be distinguished when the team sees it as a reviewed and approved change to the document.  This process does not optimally handle the situation where a change was discussed and rejected.  But it’s equally important that the team be aware of these decisions.  E-mails and a documentation trail at product team meetings are good ways to handle that, plus a general philosophy of “nothing changes until it changes – and it only changes through documentation changes.”

• Prioritize clearly.  You may think you’ve reflected all the priority calls in the creation of your requirements documents.  But almost as many decisions will need to be made after those documents are baselined as are made before.  New customer information comes in, new competitive situations arise, or, inevitably, as the design gets into more and more levels of detail, conflicts between requirements become apparent that must be resolved.  So it’s important to have a section in your requirements document that pre-defines the priorities to hasten the assessment of such new data.  A strictly ordered list of 10-15 priorities, defined along relative broad boundaries such as eventual product cost, initial product cost, performance, capacity, time-to-market, support for certain feature groups, size, reliability, power consumption, standards-conformance, etc. generally suffices.  If you get this right it allows (a) reviewers of your documents to assess whether you yourself have been self-consistent relative to these priorities, and (b) new info to be quickly assessed relative to the priorities to allow the time interval from discussion to decision to be significantly shortened.

• Implement reverse quality control.  No matter how well you write your requirements document and no matter how thoroughly Engineering reviews them, there will be opportunities for misinterpretations and disconnects.  The best way to identify such issues as quickly is for you to be part of the review and baselining team on the highest-level Engineering specs – usually the architectural specs.  As part of this process, you don’t get veto power over any architectural choices made, you only get veto power – and it is absolute veto power – if choices made are in conflict with the requirements.  And even then, there needs to be a discussion followed by a decision whether it is the requirements document or the architectural specs that will change.  If it’s the requirements document, execute on that change quickly.  Inconsistencies between the requirements documents and what is really being done can lead to a lot of downstream problems, as various entities use the requirements document as their chief reference for performing their duties.

• Provide visibility into the future.  One of the toughest things to do as a Product Manager is to determine what set of features is “just enough” for the first release and every ensuing release of a product. To achieve Time-To-Market (see next Month’s Musing for more on the importance of this), you have to throw out or defer a lot of potential requirements.  Many forces will want to drive you to add more features – feedback from the sales force, competitive data, engineers who have “pet” features, your hair stylist, etc. What I have found is that the natural tension of this process can be relieved somewhat if you maintain a plan-of-record multi-release “roadmap.” If people see their favorite feature scheduled in some release, they worry less about not seeing it in the next upcoming release.  More practically, this roadmap gives Engineering a better view into the type of future capabilities they need to anticipate and architect for, even if the features or performance or capacities aren’t requirements for the next release.  This can make the definition of future releases much easier on all parties.

• Discuss schedules honestly and schedule reasonably.  One of the biggest mistakes I see made often by Product Managers is playing games with Engineering (and vice versa) in discussions on schedules.  From the Product Management side, this often starts with the thinking “I’m going to tell Engineering we need this product on February 1st in order to get by May 1st.” The same PMs who approach the scheduling process in that way also are the ones who tend to feel it is a victory of some sort to get Engineering to “sign up” for an aggressive date.  This is wrong, wrong, wrong.  Unrealistic schedules actually delay the ultimate availability of a product program because shortcuts attempted in order to achieve the schedules backfire, and the effort to put the development program back on track takes longer than if a reasonable schedule had been worked towards in the first place.  Not only that, but the cost-of-churn as the end date keeps moving out based on continually updated guesses, is high.  You may ramp up manufacturing too early.  You may schedule and then re-schedule training.  Dates may leak out to customers that you then can’t deliver on. Marketing launches may get delayed and then re-delayed.  There can be huge costs to this – plus your credibility is shot when it comes time to get all parties to line up for the real end date.  Further, the belief behind playing games with schedules is that somehow Engineering will work harder or more efficiently if held to a tight schedule.  My experience is that Engineering will generally work extremely hard to deliver if they are a believer in the project – which it is your responsibility to ensure.  Delays are due to the ugly reality of the development process, not effort.  And those realities may get even uglier if Engineering is rushed.  So I’m a big believer that it’s way better to have a realistic – even padded - view of schedule and resources up front.  If the facts in those areas mean you shouldn’t launch the program, then don’t launch it. But that’s usually not the case.  Usually it just means the company can now confidently go out and do the things it needs to do with customers, analysts, partners, etc. required to condition the market for the future product release, without looking foolish later.  If the constituencies I mentioned see a pattern of consistency from your company in regards to your promises vs. your execution, then you will build up a halo effect of trust that will benefit you in a variety of ways down the road.

• Get them out talking to customers (the ones that won’t embarrass you).  Like most people, Engineers benefit from hearing things first hand.  Real world issues, and the way that customers make buying decisions are often foreign and distant to Engineers.  They tend to view the world through a narrower window – one in which technological advancement is automatically assumed to mean “more saleable.” It is disconcerting to them to hear that may not be true, and often the first reaction is to discredit the messenger – who is usually you.  One way to sidestep that issue, and more importantly, to make your Engineering team more customer-savvy, is to get them in front of customers on a regular basis to discuss their situations and to hear their needs first hand.  Most engineers I know, and this was my own attitude when I was an engineer, appreciate these opportunities a lot.  Of course, you’ll have to choreograph this carefully and choose the engineers to do this wisely.

(4) Write The Story Yourself

At some point, a whole bunch of people – customers, industry and financial analysts, sales and sales engineering, channel partners, co-marketing partners, and others are going to need to understand the ‘story of the product,’ i.e. what it’s good for to whom and when and how it compares to other options available in the marketplace.  Getting this story out usually involves leveraging the capabilities of Marcom, Product Marketing (if that’s not you), and Training.  I highly recommend that you feed these entities by writing an internal version of the story yourself in two forms, a Word document and a PowerPoint presentation.  In fact, you should create these documents long before you need to use them to feed Marcom, et al.  You should create a first cut of these documents even before the product program has been approved and launched, to aid the assessment process.  Both before and after approval, in one form or another, they should be used to test the product value proposition and viability with selected target customers, “safe” analysts, industry experts, and others who you feel might help to hone the story. From these interactions, you can both modify the product program (if necessary) as well as hone the materials you have created to communicate about the product.  In this way, when it comes time to leverage all of the outbound marketing resources in your company, you don’t have to spend a lot of time trying to figure out what the value proposition is, what the best messaging is, positioning, vocabulary, etc.  You can accelerate through all that and drive right towards the process of creating a wide variety of presentations, white papers, application notes, product briefs, training materials, etc., by using your time- and road-tested materials as source for all that collateral.

(5) Be The First To Cry Uncle

Ninety-nine percent of your job is to champion the products and new product realization programs that you are responsible for.  But sometimes things just don’t work out.  Early assumptions prove to be wrong.  Engineering stumbles.  A competitor beats you to market significantly.  The demand for an existing product peters out.  Any of these things and more can occur which cast a shadow on a program you are responsible for.  Since you are in the middle of everything related to the product, you will be the first one with access to enough information to determine that a product program should be cancelled – as long as you take your head out of the sand often enough to perceive it.  Others will only see a part of the situation, from one angle or another.  They may not have enough information or perhaps enough empowerment to point out the nakedness of the emperor.  But meanwhile, significant company resources are being drained.  You owe it to the company to be a business auditor as well as a champion.  But unless you are The Man With Two Brains, it’s difficult to be both an auditor and a champion simultaneously.  Also, being a champion is a 24x7 job while being an auditor is more of a sampling process.  So I recommend that you designate a couple of hours a month – perhaps on a Sunday night while contemplating the upcoming work week, to mentally assess the suitability of every program you are working on.  If a program seems to be at risk, do everything you can to put it back in shape.  But if the forces at work are external and unalterable, you should be the first to cry “uncle” and recommend the cancellation of a product program you are responsible for.

(volume 4, number 7)