Whitepaper are often regarded as “sales tools”, created after product development is complete and as part of getting ready for sales. But a whitepaper can do much more than augmenting the company’s sales collateral. It can help crystalize the product strategy and establish the value of developing a specific product or a service in the first place. After all, a product should address a specific customer need and deliver economic value – and that’s precisely what a whitepaper is supposed to communicate.

I started working as a product manager for a company that focused on developing electronic system-level (ESL) design tools. Without diving too much into the technical minutia, ESL software tools help engineers quickly model a complex system and simulate its behavior – without spending a ton of hours on its specific implementation details. Think of it as helping architects quickly sketch and visualize a large building before diving into the details of each and every part of its structure. ESL tools let engineers “play” with different concepts for a large electronic system, pick the best concept, and only then proceed through the arduous process of actually designing and building it.

The product I was hired to manage was supposed to provide a link between the ESL tool the company offered, and 3rd party hardware design tools that already existed in the market. I was very excited about the prospects of such a product, but for a while it seemed like I was the only one…

A couple of weeks after I joined the company, the engineering manager responsible for developing the product quit the company, taking half of our small development team with him. The remaining engineers on the team looked quite demotivated themselves, and I am pretty sure started looking elsewhere for a job.

It was hard to garner support for the project throughout the company. The project was generally viewed as an “interface” between our “high level” design tool and 3rd party “low level” design tools. And when engineers face the choice between enhancing and improving “our tool” vs. creating an interface to “other tools” – their preference is quite clear…

I could tell by the looks of other folks in the company that they thought my product was clearly doomed, and my days in the company were numbered. However the phrase that kept running through my mind at the time was: “It ain’t over till it’s over”.

I decided to write a whitepaper titled: “Bridging the Gap between Concept and Implementation”. It described the overall process of designing a complex electronic system – starting with the conceptual level, where key architectural choices are made, all the way through the detailed design level, where actual hardware is designed. It further described the need to develop an adequate testing framework that would ensure that both the high level model and the detailed implementation meet the desired functionality.

My whitepaper highlighted the gap that existed between our ESL tool and the other hardware design tools. The engineers who worked on the system architecture used our tool to capture the system functionality. Once their task was done, they “tossed it over the wall” to the hardware designers, who had to essentially start from scratch in a different design tool. The gap between the high level and the detailed design phases made the overall process significantly longer and much more error prone. However with the help of a “little interface” between the two types of design tools, we could dramatically reduce the overall design time, improve the final product quality, and save our customers a ton of money.

The value to the customer which was described in the whitepaper was quite straightforward. But it also pointed out the business benefits to our company. Given an interface to hardware design tools, our ESL product would get into the hands of many more hardware engineers, which meant growing the number of seats we sell, and increasing the value of each seat.

The project, officially named the “Hardware Design System”, eventually gained full management support. It became easier to recruit engineers to work on it, and our sales teams loved the prospects of making extra $$$. Once launched, the product exceeded all expectations and became one of the company’s main revenue sources. Not too bad for a “half dead product”…

I don’t want it to sound as if the whitepaper did all the “magic” by itself. It still took multiple internal meetings and heated discussions to get the message across and win support for the project. But I would say that the whitepaper laid the foundations for the whole internal campaign.

The same whitepaper, with a few modifications to fit it for external use, became the cornerstone of our outbound marketing campaign. It established the key messages, which were later used for developing all other sales collateral – presentations, datasheets, etc.

Granted, not every product development is driven by a whitepaper. But the basic tenants of ‘customer problem’, ‘alternative solutions’, ‘our solution’ and ‘why it’s better’ should be captured in every solid product requirement document (PRD). And once captured correctly, then creating a customer facing whitepaper should be mostly a “cut & paste” operation.

What does politics have to do with product management? Actually, a lot! I realize that most people view “office politics” as a negative activity that involves shameless manipulation and occasional back stabbing. I shared similar views of office politics myself. But that changed after I attended a presentation at the Silicon Valley Product Management Association (www.spvpma.org).

When the presenter got on stage, his first question to the audience was: “who amongst you likes office politics?” Hardly anyone raised their hand. He then asked the opposite question: “who amongst you dislikes office politics?” And the whole room was filled with hands in the air.

“Well, I’ve got news for you” said the speaker, “wherever there are two or more people – there’s politics”. He paused for us to absorb the news, and added: “Your only real choice is either to participate in the political process or to become a victim of it”. This was a moment of epiphany, and not just for me. I realized the speaker was right.

But wait, I am not suggesting that as a product manager you should engage in negative practices, start manipulating others, or back stab colleagues – just to promote yourself. I do however suggest that you become aware of the political processes around you, get familiar with the “rules of the game”, study the political power landscape and plan your moves accordingly.

Let’s take an example: suppose you realized that the product you’re responsible for needs a new feature urgently. Your key competitor just introduced a similar feature, and your customers give you clear indications that without this capability, your company will likely lose against its competition. The engineering team is hard at work implementing the set of requirements you’ve all previously agreed to, and the release date is quickly approaching. What do you do?

One option is to step into your weekly project team meeting and announce that the release plan must be changed to accommodate the new critical feature. Most likely, all hell will break loose as soon as you make this announcement. Fierce arguments will ensue, and chances of arriving at a decision to change the release plan are slim.

The other option is to assess who the key stake holders are, and devise a plan to get them on your side – before the critical project meeting. Let’s assume that your engineering manager is one of those stake holders. Sure, he is committed to the success of the product, but he is personally held accountable against key performance indicators (KPIs) such as delivering releases on schedule, within budget and of high quality. Changing the release plan will likely to impact some or even all these KPIs. In your discussion with the engineering manager, you reiterate the business motivation, but you also acknowledge the potential impact to the KPIs. You may propose to personally present to upper management the new market drivers for the release plan change, and ask for “readjustment” of the aforementioned KPIs. This one-on-one conversation is likely to put the engineering manager on your side. And when the subject of modifying the release plan is brought up in the project team meeting, you will have a strong supporter to back you up.

This was a fairly simple example. In reality, the political scene is often more complex, and so are the motivations of people involved. You could start feeling your way around by answering the following questions:

– Who are the key stake holders whose support I need to gain?

– What are their organizational objectives?

– What are their personal objectives?

– What objections might they have to my proposal?

– What can they potentially gain from supporting my proposal?

Once you have mapped your key “targets”, schedule one-on-one session with each one. Come prepared with the background work you’ve done, and do your best to convince them to support you. Be fully prepared to listen, as you may uncover motivations and objectives quite different from what you envisioned. Where needed, negotiate a “win-win” agreement that addresses both their objectives and yours.

Granted, not all scenarios can be planned ahead. You are likely to run into situations or meetings where the political dynamics happen in real time. As you become more proficient in the “political process”, you will be able to handle the dynamics as they unfold. Don’t just wait for the next political conflict – spend time regularly with other stake holders, understand their motivations and invest in building rapport. The more you do it, the more you succeed in steering decisions your way.

As a product manager you simply cannot afford becoming a “victim” of office politics. Your ability to influence key product decisions depends on how politically savvy you are. So rather than trying to “avoid” office politics, make it part of the skills you acquire. There are plenty of books and websites that offer advice on office politics. Take the time to read about the subject, pick those tips that resonate with you, and start practicing…