Crafting a Feature Story; or: Gong and the Three Bears

At Gong, we move fast. One of our operating principles, Act Now, states: “Instead of spending too much time discussing how we’re going to act, we simply act.” That came to play a couple of weeks ago when, amid COVID-19 and escalating shelter-in-place directives, we designed, built, and launched a feature in two weeks — all while working remotely.

Streamlining Feature Design

In an effort to move fast, one of the things that we noticed was slowing us down is feature design. Without a common language or process, each feature design was a new project, and we found ourselves debating similar issues every time.

With that in mind, the Product team recently got together on a breezy private beach (just kidding — that was just my Zoom background) to discuss some key principles for feature design and try to come up with a shared “vocabulary” or mindset that we could use to streamline our approach.

Feature Storytelling

One starting point that we’ve found helpful is this: Designing a feature is like storytelling. Once the feature is available, there should be a good “story” that can be shared with the customer about what the feature does and how to use it. So, to come up with a consistent language for feature design, we attempted to see what would make the “story” a good one.

One rule we came up with was The Rule of Three.

Every good story has three parts (beginning, middle, and end), three musketeers, or three bears (remember Goldilocks?). We’re used to seeing things broken up into three, and most writing follows this principle, as a triad (or trio of phrases or events) is thought to be more effective than other groupings. (See? Even that first sentence had three examples within it.) There’s even a Latin phrase, “Omne trium perfectum,” which translates to “Everything that comes in threes is perfect” or “Every set of three is complete.”

Distilling the Three Bears

We discussed three ways we can turn our features into better stories:

1. Come up with a feature story that has 3 parts

We can start from the top: At Gong, we provide sales teams with a SaaS solution. We call the space Revenue Intelligence, which is about running revenue teams on the basis of reality rather than opinions. (You can find out more about Gong on our website at www.gong.io)

While we could have left the Gong story at that — Revenue Intelligence — we decided to break it into three “bears” (elements or parts):

1. Deal intelligence: How can leaders determine which deals are real and which aren’t?
2. People intelligence: How can leaders understand what makes certain people top performers?
3. Market intelligence: How can leaders understand what happens in the market?

And while we can say a lot about how Gong works, we typically focus on the following:

1. It captures your interactions with customers.
2. It understands them.
3. It delivers insights.

The same goes when designing a feature. We can start out by identifying its three bears.

For example, when sales professionals review a deal in Gong, they check the prospect’s account in what we call the Account Page. When we explain that page to customers, we might highlight the following:

1. Review who you’re working with (contact, rank)
2. Review how much you’re interacting with them (quantity)
3. Review how well you’re interacting with them (conversation quality)

Here’s an example of how this looks:

Similarly, when sales professionals review a sales call in Gong, we’ve organized the feature to highlight these:

1. Listen to the call itself
2. See what’s inside the call
3. Collaborate around the call

This is how it’s organized on the page:

The features (or the pages, in this case) have many other elements, but we find it helpful to first identify and focus on its three main parts and then drill down from there.

It bears mentioning (heh) that we can’t always identify the three bears when the feature is conceived. In fact, we may only start with one bear, but as the feature evolves, we should be able to come up with the two others and of course the compelling story tying them all together.

2. Avoid the antiquated rule of seven

The rule of three stands in contrast to an old Rule of Seven.

In 1956, Harvard professor George A. Miller published a paper titled “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information,” in which he argued that most people’s short-term memory could only hold between 5 (7–2) and 9 (7+2) chunks of information, thus making 7 the “magical” number. That’s the theory that drove a lot of the feature and interface design we’re familiar with.

Here’s how Google Docs system looks (8 items):

But “capacity” in the 1950s and even 1980s and 1990s was a different beast (or bear, if you will). In 2020, we’re all feeling pretty much at capacity already, so 7±2 is too much. Plus, by now we know that we all do better with a story than with a long laundry list of items.

If we followed the old rule of 7 on our Account Page, the page might have had numerous tabs, like Contacts, Activity, Topics, Trackers, Warnings, Collaboration, and Scorecards. But clearly the poor user would have a hard time understanding the meaning and functionality of each item. We have to keep our bears to a minimum.

3. Organize a larger number of items into a hierarchy

We often start feature design with a larger number of items or concepts. This is very common with setup pages of sorts: business software tends to give customers a lot of control over how the software works.

In such a case, we can organize the items into a hierarchy based on the Pareto principle: 80% of the users will use 20% of the capabilities.

For example, here’s an area that lets administrators set up how to import users from Salesforce (a CRM) into Gong. It addresses three questions, each building on the previous one:
(1) whether or not to import users;
(2) which users to import;
(3) whether to disable users who are deactivated in Salesforce in Gong as well.

The third layer (under Some users) is hidden, and the complexity is revealed only when the administrator selects that option.

As product managers, we can leverage usage data to build the hierarchy. If we’ve already launched a feature and we see that 80% of the use is around a certain function, area, or option, we can package the other 20% lower in the hierarchy.

However, in some cases, the data may not exist or may be misleading. Users may not be using an option because they don’t understand it, or because its implementation is not adequate.

As for understanding data, have you ever seen a person and a dog walking on a sidewalk (in the pre-COVID-19 days, of course)? To an outsider, it may look like the dog is leading the way, but once the two reach a crossroad, both stop, and the person pulls the dog in the desired direction.

Product teams cannot always be led by data

As product leaders, data can help, but we need to get to underlying use case:

1. What do people need?
2. What should they use/need?
3. Do we understand why the numbers line up the way they do?

Final thoughts

The Rule of Three is only one aspect of feature storytelling, and just one tool in a product manager’s toolbox. As always, it’s not a fit for every situation, so you should choose your tools based on your context. In the coming weeks and months, we’ll share additional tools and methods we use. Stay tuned.

In the meantime, let’s hope that despite the current trying times, we all get to live happily ever after.

The end

PS: I would like to thank the Gong product team for having a fruitful discussion around this topic and for taking part in this write-up. I would also like to thank Sagee Ben Zedeff and Boaz Katz for providing feedback on an early version of this post.