Creating a Story Architecture Built with Precision Stories
In this recording, I’ll describe how to create a Story Architecture built with story modules or what we call Precision Stories.
Making the Consensus Sales
First, however, let me make the point that CEB/Gartner describes today's sales environment as Consensus Selling, as they discovered that on average, 5.4 people are involved in a typical B2B purchase decision.
These 5.4 people need to be educated on what you have to offer, and although they most likely come from a diverse set of functional areas, they are asking four fundamental questions:
- Why should they not do what they're already doing today? In other words, why should they care about what you have to say?
- What is it you do?
- How does it work?
- Who else uses it?
A story architecture built for your product or service answers these four fundamental questions, organized modularly with recordings of 8 minutes or less,. Each story modules we call a Precision Story.
These Precision Stories are recorded by your assigned storytellers, whom ideally are the people you’d most like in front of your customer telling their assigned part of your overall story.
Selling is Educating
One of the primary objectives for creating a story architecture built with Precision Stories is to enable your sales team to coach your customers on how better to run their businesses.
First Start by Answering the “Why”
Therefore, in developing a story architecture, the first step is to identify the why insights, answering the question: “Why your customer should NOT do what they are doing today?” en route to making changes coached by your sales team that will enable your customers to better run their businesses.
What is the Current Status Quo
To create these why insights, we begin by identifying what is the current state, or status quo for your potential customer. In other words, how is your customer conducting his or her business today?
What is the Desired State
Next, we have to understand what is wrong with this status quo because there is a better, “what could be” desired state.
Start with the NOT, Answer the Why
In other words, top enterprise sales are able to coach their customers on what they should NOT continue to do in their current, status quo and the reasons why.
Building the NOT Insights and Reasons
Therefore, in the first step of developing a story architecture, we need to identify the why insights and give the supporting reasons.
Why Your Customer Should Care?
It’s important that your sales team coach their customers first with these why insights because it helps them to understand why they should care about what you do, which presumably provides an answer that will lead the customer to the new more desired state.
When done with this step, you should have 3 to 5 or more why insights.
PrecisionStory Why Insights
For instance, in PrecisionStory’s case, one insight is you should not tell your story relying on large text-based collateral such as 10-page whitepapers, because:
- Large text documents are too hard to consume on mobile, where we are getting a lot of our content these days,
- Busy professionals don’t have time to read large text-based documents
- The creation of these documents is expensive and takes a long time
- Finally, there is lack of agility, meaning these documents tend to get out of date but given the high cost and time required to create, they don’t tend to get updated
What Does It Do
Next, you need to structure what capabilities exist in your offering that solves each of the reasons why a customer should change from status quo.
What with Value
These capabilities will have value statements associated with them. These values tie back to the value that your customer attains from adopting the insight and changing from status quo to deploy your offering.
In PrecisionStory’s example, one reason given for not building large text based documents like whitepapers is that this approach is inflexible, resulting in outdated collateral.
In response, one capability we have is our approach leads to a modular design. We then add Story Release Management, which means that any particular Precision Story can be updated at anytime should it be decided there is a better way to tell the story.
An associated value to this modular design approach is very agile storytelling, as individual Precision Stories can be updated at anytime without impacting the rest of the overall story.
Who stories mimic reference selling. Besides describing who the customer is, the primary questions answered in who stories include:
- What particular capabilities in your product are being used by this customer, and
- What has been the value received by deploying these capabilities? In this way, the customer story becomes a proof point for at least one value articulated in your What stories.
- Why did the customer change from status quo, which should align with at least one reason in one of your why insights, and
- Why the customer didn’t go with the competition. This reason why provides a proof point that the capability – value you offer is better than what your competition brings to market.
Finally, we have the how stories which explain how the product works. How stories should touch upon all the described capabilities.
When done, your story architecture will consists of a number of well-defined story modules or Precision Stories, answering the Why, What, How and Who questions.
When building, we recommend each Precision Story be told in less than 8 minutes by an assigned storyteller who ideally is felt will do a great job telling the assigned story.
Note, we can add in the transcript text so individual Precision Stories can be repurposed for instance as external blogs. We can also create quizzes for each Precision Story so the overall story can be re-purposed for sales and partner training.
Building a Story Architecture with Precision Stories
If you’re interested in learning how we actually build a Story Architecture, please watch the next video: How to Implement a Story Architecture with Precision Stories.