Develop a buyer’s guide to educate your startup’s sales team and customers

Every company wants to be innovative, but innovation comes with its share of difficulties. One key challenge for early-stage companies that are disrupting a particular space or creating a new category is figuring out how to sell a unique product to customers who have never bought such a solution.

This is especially the case when a solution doesn’t have many reference points and its significance may not be obvious.

My view is simple — some buyers could use a walkthrough of the buying process. If you are building a singular product in a nascent market that necessitates forward-looking customers and want to drastically shorten sales cycles, I have a proposal: Create a buyer’s guide.

A buyer’s guide is essentially a prescriptive summary that provides an understandable overview of how a customer may buy your solution.

A buyer’s guide is essentially a prescriptive summary that provides an understandable overview of how a customer may buy your solution. What does your product actually do? Is it secure? How would you implement the technology? What does it replace, if anything? It should be short, simple and speak the customer’s language. It also acts as a sales-enabling tool. Sales teams, especially at smaller startups, can review the guide quarterly and analyze what is and isn’t working as the company goes to market.

Here is how to put together a buyer’s guide, including what to sort out before you type a single word.

Know your audience

From the start, it’s important to think about who the stakeholders are for your product’s buying cycle. One typical issue with early-stage startups is they meet with an enthusiastic buyer — a CIO, CTO or VP of product — but neglect to include the other stakeholders who should be part of the conversation. More importantly, a lot of companies don’t realize the impact of their product on a group or team that they would not typically sell to.

For example, target the security team as an early stakeholder, because they’re probably going to review your product. If the solution is focused toward, say, integration, then hone in on who would be owning the integration process on the buyer’s team.

If you’re selling a martech solution, on a business level, you have to consider a finance business partner for marketing. Think about the problems your customers face and also how others in their company relate to them.

As you move through the sales process, other decision-makers start to get involved. Including all pertinent stakeholders early, besides the sponsor and primary stakeholder, mitigates the friction this causes and shortens the sales cycle. In your buyer’s guide, identify the stakeholders that you as a salesperson or founder/CEO want to have touch points and share information with about your product.

Deployment, security and the buying process

At this point in the process you’ve already made a sales pitch and have had multiple conversations with stakeholders, but a quick refresher on the value proposition of your solution is nice to include in your buyer’s guide. Add the deployment details here as well: the expected results of deploying your product, the measurable goals you have in mind for the proof of concept (PoC) phase of the sales cycle. These goals can also be outlined or reiterated in the PoC section itself.

The first half of the buyer’s guide should also comprise a one to two-page security narrative around your product. This allows the procurement team, your customer contact or the person who referred you to the company to make sure the company is on the same page. The objective is not to have a boilerplate run-down of your security policies and processes, but a more narrative-driven outline that addresses your company’s security culture, who is responsible for security at your company, certification details and other important information.

Next, talk about the actual buying process, end to end. You can kick off the buyer’s guide with this section or include it later on. The buying process should be a high-level summary of what the customer should expect after the first meeting. It should outline everything that needs to happen if they decide to sign on the dotted line.

After you’ve had the first meeting with a customer, what should they expect to happen? In most cases, the next steps would be to provide a security document, set up a follow-up meeting to test the solution, conduct a review of the customer’s tech stack and engage with other stakeholders. You may have some enthusiastic buyers who want to orchestrate the buying process in some way, shape or form. Having the process portion of your buyer’s guide down pat will enable you to control the narrative.

Overeager buyers who want to fast-track the process won’t get far unless all decision-makers are on board. Even the most autocratic of C-level execs can be redirected by the procurement team — not stopping a deal or purchase from happening, but by bringing up valid concerns that could place their company at risk. In your buyer’s guide, defining what the buying process entails keeps everyone apprised of next steps and prevents buyers from jumping ahead.

PoC, customer success and implementation

A key part of your buyer’s guide should begin with an overview of the PoC part of the sales process. The PoC is essentially the trial component, where buyers can test out a product and witness its value proposition and market differentiation firsthand. This one-page summary should point out some of the technical requirements of the PoC along with the results buyers should see when they test out the product.

Say you have an automated solution for financial transactions. One of the goals for your PoC would be to automate X percentage of transactions or events. Another goal may be minimizing the number of errors a buyer typically sees, or showcasing ease of deployment. Whatever it is, be prescriptive when setting expectations.

Here are some questions to address in your PoC one-pager: What does the PoC look like and how long does it take? What are the integrations required? Who is involved in executing the PoC? What permissions are needed for access? What communication should be happening, and to whom, about the PoC? What are common hurdles or false positives that have arisen in past PoCs, and how can these be avoided?

After the run-down, talk about what ongoing customer success looks like and what buyers should expect from a cadence standpoint. Define what the customer success team does and does not do, what a typical engagement between the customer success team and the customer looks like, what kind of reporting the customer will receive, how long it will take to review feature requests, and other considerations.

Make sure you have a set of reference case studies handy. It may feel like you’re creating a brochure as you put these case studies together, but you’re merely being more informative. Encourage your prospect to reach out: Speak to this reference customer because they are similar in size, or speak to this one because they’re in a comparable industry. And so on.

End your buyer’s guide with a run-through of the implementation phase. Clarify the timeline, who should be involved, and how to plan for resources. Many times, CIOs will make the mistake of saying, “I’m just going to buy a solution,” without thinking through the logistics of what happens after a purchase is made. The administration of a software product is carried out by someone who’s already very, very busy. With little or no heads-up, this makes their job incredibly difficult.

Always tell a story

The buyer’s guide is a win for both sides: Buyers are informed of what’s to come, and startups can expedite a potential deal by preempting any concerns about a product and/or the sales process. The order of the buyer’s guide isn’t entirely set in stone, but the sections outlined above are crucial. Identify your stakeholders, describe your solution’s value, deployment and security measures, summarize the buying process, and trace the steps of the PoC, customer success and implementation stages.

Don’t think of the buyer’s guide as a document. It can be written at length as a narrative or be a series of slides. Above all, it should feel like a cohesive story that threads all of the sections together. If you’ve made it this far then your storytelling abilities might be just as special as your product.

Think of the buyer’s guide as another chance to flex those narrative muscles, and streamline your path to a “yes” while you’re at it.