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 3^rd 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 3^rd 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.