With 79% of online readers strictly skimming their content today, we can safely assume that people crave writing that gets to the point and gets to it early.
Whether it’s an article or an internal wiki post, people want to consume it as fast as possible. As a result, if your content can’t cut to the chase, your readers will likely bounce to the next article that will. In fact, according to research from Nielsen, websites only have 10-20 seconds to grab a user’s attention.
However, there is a silver lining that you can pluck from that unfavorable statistic. Namely, communicating a key takeaway right away can potentially hold your audience’s attention for the entire duration of your article.
This still begs the question, though — how do you get to the point, and how do you do it in an engaging way? We recommend following the Minto Pyramid Principle.
What Is the Minto Pyramid Principle?
Coined by Barbara Minto, a former McKinsey consultant, the Minto Pyramid Principle is a writing framework that suggests structuring information in a pyramid format. At the top, you start with the most important takeaway. Then, from there, you support your conclusion with layers of evidence that flow in a logical order.
Structuring your information like this allows you to instantly convey the takeaway that your readers are looking for and then prove its value throughout the rest of the article.
How to Follow the Minto Pyramid Principle
At the Article Level
Just like a pyramid, your article’s premise, which should be stated in the introduction, will sit at the very top of your article. Then, each of your “whats,” or key points, will branch out from your premise. Next, the “why,” or your supporting evidence for your takeaways, will branch out from each point. Finally, the “how,” or tactical, practical advice for executing the main takeaway, will branch out from each “why.”
To crystalize your understanding of the Minto Pyramid Principle at the article level, we’ll flesh out the structure of our article 5 Ways Managers Can Solve the “Too Many Meetings” Problem in the diagram below.
Premise: How Managers Can Solve the “Too Many Meetings” Problem
Takeaway 1: Run Asynchronous Meetings
- Evidence: Team can contribute to the discussion on their own time
- Advice: Decide on a day that everyone can “meet”; Create a page in internal wiki for each meeting
Takeaway 2: Report Metrics in Your Wiki Instead of in a Meeting
- Evidence: Metric reporting meetings rehash information that everyone can read on their own
- Advice: Ask your team to discuss how they ‘d act on the data at hand; Use your wiki page’s comments to hold that discussion
Takeaway 3: Share Background Information in Your Wiki to Shorten Meetings
- Evidence: Allows your attendees to prepare for the meeting beforehand and cover more important items on your agenda
- Advice: Share any background information about your meeting in a wiki doc; Link the background information doc in your meeting agenda
Takeaway 4: Pitch New Projects Through Forms, Not During Meetings
- Evidence: Gets rid of the need to meet about new ideas
- Advice: Create a page on your wiki that your team can submit tickets through; Forms should include fields that ask them the what, why, and how behind their project
Takeaway 5: Teach Your Team How to Protect Their Time in Your Wiki
- Evidence: Your team will have a resource that they can always reference to help manage their time
- Advice: Teach your team how to determine whether a meeting request is worth accepting; Update your wiki posts as you gain more knowledge about protecting your own time
Notice how each section boasts a sound logic that’s easy to follow? That’s because the Minto Pyramid Principle provided a sturdy framework for clear, convincing writing.
If you’re wondering how we ordered our main points, we approximated how much our audience would value each takeaway and ranked them from most helpful to least helpful. If this were a story, however, we would list our main points in chronological order.
At the Section Level
Just like the structure of an article, each section will cover its own “what,” “why,” and “how” in that exact order.
Using the same example article as above, we’ll deconstruct the section about reporting metrics in your wiki to help you grasp the Minto Pyramid Principle at the section level.
In this example section, our “what,” or main takeaway, is “report metrics in your wiki instead of in a meeting,” which is also the section header.
Next, we dive into the section’s “why.” Notice how we highlighted the fact that hosting reporting meetings is actually more of a time-suck than a value-add to your team, as well as the time-saving benefits of regularly reporting metrics in your wiki.
“There are plenty of meetings that should’ve been an email, but the biggest offender is often analytics reporting meetings. We’ve all experienced the pain these meetings inflict. Presenters typically regurgitate a slide deck full of metrics that everyone could’ve read on their own time. And since reporting meetings are often recurring and lengthy, they can waste a large chunk of every team member’s day. Instead of hosting this time-consuming meeting, salvage part of your team’s day by regularly reporting metrics in your wiki. ”
Last comes the “how.” Check out the tips we dish out in our example section below.
“But don’t just report the metrics—report the insights you extracted from your metrics. Data is just a bunch of numbers packed into a spreadsheet. What makes it valuable are the learnings within. So, in your reporting document, ask your team to discuss which factors impacted their performance the most and how they can act on the data at hand. You can use your wiki page’s comments to prompt engagement and discussion about this data. This will also allow you to see which of your teammates read the reporting doc and which didn’t.”
Cutting to the Chase
For most of us, the Minto Pyramid Principle is the opposite of what our high school English teachers and college professors taught us. But you must remember that they were paid to read our writing. In the real world, the only currency that people pay to read blog posts and internal wiki articles is their attention. So, start collecting that attention — by cutting to the chase.