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.

Developing, manufacturing, promoting, selling and supporting a product involve multiple departments within a company. A typical division of responsibilities may look as follows: The engineering department designs and develops the product – be it a hardware device, a piece of software, or a service. Manufacturing is responsible for building products in quantities to meet demand. The marketing department promotes the product using vehicles such as public relations, advertising, tradeshows, etc. The sales department is responsible for selling the product to potential customers. And finally the technical support department resolves any problems customers encounter while using the product.

With multiple departments involved in each product life cycle, coordination and alignment become critical to product success. Orchestrating the activities of all the departments involved is the primary responsibility of a product manager. In many respects, the product manager is the ‘Chief Executive Officer’ (CEO) of the product.

The challenge that every product manager faces, is that unlike a CEO, the various departments involved in the product lifecycle do not report to him. A product manager is rarely in a position to “order” a manufacturing manager, or an engineering manager to do the right thing for the product. The secret to a product manager success is the ability to convince the various departments to march in the same direction and effectively collaborate to ensure product success.

The product manager primary job, and a key to his /her success, is to build a leadership position; a status that will grant them authority over the various departments. The process of building product leadership requires the use of political skills – in a positive sense. It certainly helps if upper management provides the right backing for the product management team. But at the end of the day, it is the product manager who must handle the daily challenge of maintaining his/her product leadership status.

Assuming job #1 has been accomplished and the product manager has leadership/influence over the other departments, his responsibilities should include the following:

Product requirements: identify the key customer requirements engineering should implement in a new product, or subsequent releases of an existing product.

Feature prioritization: reach agreement with engineering on the priority and implementation order of features, and the actual content of a product release.

Release planning: plan a schedule of future releases that introduce new features and necessary fixes.

Pricing: of the various product offerings, options and related services.

Messaging: define the key messages and the product positioning. Work with the marketing department to deliver those to customers and partners.

Competitive positioning: analyze competing products/services in the market and define key advantages to be highlighted during the sales process.

Sales enablement: create educational materials and train the sales force on how to best position and sell the product/service.

Crisis intervention: become involved with, and help resolve major breakdowns that occur at strategic customer deployments.

Product management is one of the most complex and challenging positions within the organization. As the saying goes – “Success has many fathers, while failure is an orphan”. When a product succeeds in the market place, engineering takes credit for building a great product, and sales will pride themselves on their ability to drum-up customers. But when a product fails, the product manager may find himself carrying the blame: feature requirements weren’t clear, or incorrectly prioritized; messaging was murky; sales were never properly trained; etc. So why should anyone wish to hold such a position?

If you love to drive a team, build consensus and watch it succeed in creating something new. If you like to deal with multiple disciplines, and interact with all parts of the organization. If you love engaging with customers and keeping your fingers on the industry pulse. If you want to exercise your analytical skills, communication skills, and people skills – then you will find the role of a product manager ideal for you. And if you dream of becoming a CEO of a company, there is no better training than a product manager job.