Playbooks drive a successful proof of concept project

When asking customers to evaluate your product in a proof of concept project, provide playbooks to help drive successful outcomes.
4 min read
Share on linkedin
Share on twitter
Share on facebook
Share on email

Asking customers to run a proof of concept project is a terrific way to reveal your product’s value propositions to them. The problem with such projects is, you’re betting everything on a successful outcome. So, if you’re going to bother with a proof of concept project, then at least make sure you guide the customers running it to successful outcomes by providing them a proof of concept playbook.

One of the more interesting projects we’ve done lately was a set of proof of concept playbooks for Microsoft. This project got us really thinking about what makes a proof of concept project successful. It also gave us a deeper appreciation of the risks associated with poorly documented projects. If your proof of concept project fails, the potential customer walks. You can’t mess this up.

Proof of concept fails

When customers work on a proof of concept project without following clearly defined playbooks, two issues can arise:

  • Lack of clear objectives. A proof of concept project provides previews of how customers might use your products to solve specific business challenges. Without well-defined objectives, customers tend to lose focus on the business challenges they’re trying to solve. Chaos ensues.
  • No consistently measured success criteria. This issue is a byproduct of lacking clear objectives. Without outlines for the proof of concept project and clear instructions for building and demonstrating it, there’s no way to quantify the project’s success. Without the ability to measure success, customers can’t determine your products’ value to their business.

With either issue, a proof of concept project can fail outright or simply fail to prove your products’ value propositions. Both outcomes cause nightmares for product managers.

Business requirements drive a successful proof of concept project. These projects have well-defined scopes, stick to well-defined structures, follow precise implementations for each use case, and properly document the results. That’s just too much to ask customers to figure out on their own, especially considering what you’ve got riding on the outcome.

Proof of concept project elements

The key to a successful proof of concept project is to give customers proof of concept playbooks that drive their evaluations of your products. Doing so gives you some control of the outcomes. These playbooks should define for customers the following core elements of a successful proof of concept project:

  • Scope definition. This element describes the business challenges customers want to use your products to solve. Ask customers to document their challenges and choose proof of concept themes (more on themes later) that align with them. It’s also important to ask customers to document what a successful outcome looks like for each challenge.
  • Project structure. Organize the proof of concept playbook in a way that tells stories that address specific business problems. We recommend organizing playbooks into a hierarchy of (1) themes, (2) scenarios, and (3) use cases. Themes define business problems, scenarios outline specific examples of those problems, and use cases provide step-by-step guidance for using your products to solve the problems the theme describes. Every step of every use case must define a success criterion to help determine whether that part of the project was successful.
  • Roles and responsibilities. Include fictional personas in your proof of concept playbooks that customers can relate to real users in their organizations. These personas are an important part of the storytelling that takes place in a proof of concept project. Also, ask customers to clearly define project sponsors and presenters. Defining the sponsors helps keep discussions focused on their needs, but presenters should be the only people steering the project.
  • Project timeline. A proof of concept project should follow a specific timeline: launch —> perform —> analyze —> close. Direct customers to perform one theme and scenario at a time to keep conversations focused and avoid confusion.
  • Project closure. Ask customers to close the proof of concept project by recapping the outcome of each theme, scenario, and use case. Presenters should leave the sponsors with a high-level summary of the project.

Proof of concept project playbook

We recommend that you organize your proof of concept playbooks as follows:

  • Themes. Themes represent common business challenges. Playbooks can contain multiple themes that you use to develop the framework for a proof of concept project. Themes typically have prerequisites and setup steps that you must define for customers. For example, if the proof of concept project focuses on a software as a service app, a prerequisite may be that customers have tenants. Theme-level prerequisites apply to all the scenarios that make up that theme.
  • Scenarios. Scenarios are the specific examples of business challenges the theme defines. Each theme typically contains multiple scenarios. Ask customers to choose one or more scenarios within each selected theme that relate to business challenges they want to solve. Like themes, scenarios may have prerequisites and setup steps that you define for customers. Also, scenarios should include clear setup instructions for each use case they contain. Poor setup documentation can lead to a regrettable—but completely preventable—failure.
  • Use cases. Use cases provide detailed examples of how to solve the business challenges a scenarios defines. A scenario likely contains many use cases. Use cases are the truth tellers in your proof of concept playbooks, so make sure that you provide clear, step-by-step guidance for demonstrating each use case. Of course, a use case can’t tell the truth without some criteria by which to judge it. Therefore, every use case must include success criteria. What defines a successful outcome for each use case? Don’t ask customers to offer their interpretation. These criteria must be objective: Did the use case work or did it not work?


Give customers proof of concept playbooks that they can use to select, set up, demonstrate, and measure the outcome of use cases. By doing so, you steer customers toward a successful evaluation of your products without leaving anything to chance.

For more information about the proof of concept playbooks we built for Microsoft Intune, visit our Project page. If you’d like a one-on-one demonstration of these playbooks, don’t hesitate to reach out and say hello.

About the author

Chris Howie

Chris Howie

Chris Howie is an IT pro who’s passionate about helping customers, both technical and nontechnical, realize the full potential of their IT investments. During his 10 years of consulting for government and education customers as well as Fortune 500 companies, he has been an advocate for Microsoft Azure, Intune, and System Center; Windows and Windows Server; Forefront; and many other Microsoft technologies. Chris holds MCSE and multiple MCSA and MCTS certifications.