I’m passionate about creating white papers and other long-form content and self-admitted white paper purist. My white paper creation process is pretty straightforward.
Here’s my process for creating white papers:
1. Ideation
Much like article writing, I’m in a near-constant state of ideation. My non-linear thinking mind enjoys the art of pitching ideas.
When it comes to white papers, I take a multilayered approach to the ideation of potential white paper topics, including:
- Track industry trends against my organization’s current thinking for new angles
- Track content needs from sales and business development for white papers that can help differentiate my organization in the market
- Follow what competitors are speaking and writing about, analyze gaps, and
I recommend having a formal or informal approval process for ideas as a gate to exit this phase
2. Planning + research
While I can start with a blank page and be OK to start my white paper creation process, taking the upfront time to write a creative brief for the white paper is something I plan to explore doing in the future.
Research for a white paper usually takes place online and through subject matter expert (SME) interviews. When a white paper concept comes from my own experience, I use this phase to validate my approach and thinking.
The exit criteria for this phase should be completing your research. However, fast-moving topics such as DevOps and the cloud require
3. Writing the first draft
Now I take the outputs from the first two phases and write my first white paper draft. I like to write in Microsoft Word or Google Docs using a simple template that can generate a table of contents. Keeping the writing format simple makes it easier to pull the content into InDesign or another design package for layout.
4. Conducting a technical and marketing review
Technical and marketing reviews can be a challenge with conflicting priorities. I try to determine potential reviewers and backups early on in stage 1. I seek out reviewers during the white paper’s ideation phase when possible and feasible.
It’s rare for an organization to do document reviews well it seems in my experience. It’s worth spending some time in the earlier phases to set expectations for your reviewers up front even setting guidelines for them.
5. Revise + iterate + finalize
I use the editorial and technical feedback from the previous phase to revise and iterate my white paper content. I also make time to resolve any contradictions among the reviewers. If the white paper comes from my POV, then I use this time to ensure that none of my thinking has changed due to market events or changing technology trends.
Depending on organizational and team culture, I often must make a last call for review comments. I aim to get the best white paper possible as the output for this phase.
6. Design + publish
Once the content is final, I send it to design and production. Commonly, this is an outsourced design firm or, in cases of large companies a separate department. Once the white paper comes back from the designer, I typically put the white paper through another review cycle to ensure there are no layout or design issues.
Iteration is my copilot
A white paper on a technology topic shouldn’t be a one-and-done affair. If I was to write a white paper process today, I would definitely factor in a secondary process and cadence for updating and releasing white paper updates.