The Rule of Three in Marketing

The Rule of Three simply states that after more than three of anything people start have trouble retaining it in the short term or “active memory”. Three is the smallest number of items to formulate a pattern, and that coupled with the succinctness correlates content that sticks with people.three-1182800-640x480

The Rule of Three for marketing has applicability for website messaging, bullet points, presentations, sales pitches, sales campaigns and more. Why overwhelm your audience with lots of information that they will not retain anyways? Consider that marketing organizations often feel compelled to bury prospects with details, details and details. Save the details for white papers and data sheets. Content marketing is more about having conversations with customers and you need to make that conversation count – gaining mind share means filtering and distilling the details into a simple, concise message.

There are many examples to illustrate this point from communications, advertising, marketing, management and many more so let’s look at some to drive this point home.

Throughout history, information presented in groups of three has had staying power, here are just a few notable quotes:
“Life, liberty, and the pursuit of happiness”
“Government of the people, by the people, for the people”
“Duty – Honor – Country.”
“Friends, Romans, Countrymen”
“Blood, sweat and tears”
“Father, Son and Holy Spirit”
“Mind, body, spirit”
“I came, I saw, I conquered”

Many of these quotes use similar words are used to express one idea, but how about the famous real estate mantra, “location, location, location” where the same word is repeated for emphasis. Moreover, Tony Blair, former Prime Minister of the United Kingdom said in a speech that the three main priorities for government were, “education, education, education.” This is a spinoff from the general principle of advertising that a product should be mentioned three time to make sure it staying power with the audience.

Steve Jobs consistently utilized the Rule of Three in his product launches and product messaging:

In 2007 Jobs introduced the first iPhone as the “third” of Apple’s revolutionary product categories (the first two were the Macintosh and the iPod). He even said that Apple would be introducing “three” revolutionary products—a new iPod, a phone, and an Internet communications device. Jobs repeated the three products slowly until the audience finally figured out he was talking about one device capable of handling all three tasks.

In 2010 Jobs introduced the first iPad with a slide showing the new tablet as a “third device” between a smartphone and a laptop. The iPad, he told the audience, would also come in “three models”: 16, 32, and 64 GB of flash storage.

In 2011, Jobs introduced the iPad 2 as “thinner, lighter, and faster” than the original. The three adjectives so accurately described the new device, thousands of blog and newspaper headlines included those three words.

The rule of three applies visually, for presentations, it is a common principle to focus on three main points. Moreover don’t forget another classic principle for presenting which also comes in a pattern of three:
1. Tell them what you are going to tell them
2. Tell them
3. Tell them what you told them

The three-act structure breaks out any narrative such as a play, movie, story, etc., into three parts, often called the:
1. Setup
2. Confrontation
3. Resolution
Although simple in nature, it has withstood the test of time, being used by Alfred Hitchcock, Sir Arthur Conan Doyle, Shakespeare, and Aristotle.

With the Marine Corps, which is actually a very agile and innovative organization, the Rule of Three is a key principle stating that an organization is most effective when each management level is supported by three components. Marine Corps infantry units follows the Rule of Three, which places three subordinates under a commander, not counting support elements. Supporting units will have their own organization and equipment, but generally also follow the Rule of Three.

Survival skills has their own Rule of Three to:
• You can survive for 3 Minutes without air
• You can survive for 3 Hours without shelter
• You can survive for 3 Days without water
• You can survive for 3 Weeks without food

The TSA has three simple steps to convey its messaging to aid passengers in getting through security:
1. Show ID and boarding pass.
2. Take out liquids (in a baggie) and laptops.
3. Take off shoes and jackets.

Hopefully by now you have become a believer and take the Rule of Three principle to task in your next presentation, campaign or messaging.  Less is more – use the Rule of Three.

Mining the Support Organization for Product Roadmap Data


The product roadmap that is communicated throughout the organization is actually the result of considerable research that includes:

  • Customer feedback
  • Internal factors
  • External factors (using the STEP model – Social, Technological, Economic, and Political trends are all analyzed)
  • Competitive analysis
  • Sales analysis (win-loss)
  • Product analysis (a subjective and objective checkpoint of the product in its current state)

It is the last item, Product Analysis, where mining your technical support database can lead to some enlightening and useful information to drive the future direction of the product. In the past, I have mined this empirical data as a measurable means to understand the strengths and weaknesses of the product. This comes in three forms:

  1. Customer-requested features by function
  2. Customer-reported bugs by function
  3. Support incidents by function

For each of these three components, I have found it most useful to have this data grouped by functional category. This provides a measure of what areas of the product customers find lacking (feature requests ) or problematic (bugs and support incidents). For one analysis that I did, the same two functional areas of the product bubbled right to the top for having the most feature requests, reported bugs and overall support incidents. Recommendations from a Product Manager are best when the are backed by data – what better “ammo” to have to convince anyone of where the focus needs to be.

Pulling and massaging this data is dependent on the solution that technical support uses, however, it is most likely to be there in some shape or form for the taking. Once you have created a process for assembling the information subsequent updates on a quarterly or annual basis becomes easier and allows for comparison from past analysis – for example do support incidents or bugs routinely come from the same functional component of the product. If so, then a problem still exists and warrants an action plan.

This has an added benefit of building bridges and good relationships with the technical support organization so they feel empowered and part of the team. In other words, as the Product Manager you will be exhibiting a sound cross-functional leadership role.

Does your phone buzz you to distraction?

Back when smart phones were beyond the early adopters and into the pragmatist stage (thank you Geoffrey Moore and the technology adoption lifecycle introduced in Crossing the Chasm) I was sitting in my Director’s office having a 1:1 meeting.  Our phones kept vibrating for every incoming email and since we were on many of the same distributions, oftentimes the phones vibrated simultaneously – it was a cacophony of sounds and vibrations.  Right then we decided to shut off our email notifications (on our trusty state-of-the-art Blackberry’s no less).  I have never looked back.

The ability to multitask seems to be a badge of honor in today’s fast-paced work environment but is it more productive?  Not really, and now this new research suggests that just hearing your phone buzz hurts your productivity.  In a similar Harvard Business Review report, digital distraction was christened, “the defining problem of today’s workplace,” – and it starts and ends with our phones.  Moreover let us not forget to mention the impact of notifications with people’s driving behavior – how many times do you see people sitting at a green light because they are focused on their phone and not the green light?

So take heart, shut down your notifications, don’t feel guilty about and be more productive!

Never invite sales people to a meeting

Mark Officer:

Excellent blog! There is another danger in inviting sales people to a meeting. Feature requests that come from sales are often based on their opportunities and their financial gain if a sale in their forecast closes. Product managers need to be more holistic in treating feature requests. This is not to say that it may my be a worthy feature but it does require additional validation and evaluation.

Originally posted on Steve Johnson < Under10 Consulting:


In a well-run organization, each role has a single orientation; they either support [individual] customers or they support the market.—Peter Drucker, American management consultant.

What do you think sales people should be doing?

(It’s not a trick question.)

The things you probably thought of were: building relationships with customers, helping them configure the right solution, negotiating, and closing deals. In short, selling what we have to people who want it.

In your list, did you also think sales people should be creating product presentations, developing ebooks, and determining the industry events to support?

Would you be surprised to learn roughly 50% of sales people’s time is spent working on things that do not generate revenue? In short, half the time, sales people aren’t working toward their objectives but are providing market expertise to the rest of the organization.

How often do you find yourself saying, “Let’s ask the sales people…

View original 458 more words

How to Conduct a SWOT Analysis the Right Way

Previously I posted a blog on my version of a SWOT Analysis Workflow.  I summarized this article into this Slideshare presentation How to Conduct a SWOT Analysis the Right Way.

I did this for two main reasons, namely to emphasize that a SWOT analysis needs to be based on research which is why the situational analysis is a prerequisite, and secondly the SWOT diagram that everyone is familiar with, while is it a great visual tool it needs to be followed up with a set of recommendations (the roadmap).

The importance of listening (and always asking questions)

When talking with customers, it is not enough to take their feature requests at face value.  What they ask for may not necessarily be what they want. Here is an example of a conversation I had with a supervisor of data entry users for a transaction-based processing solution:

User: We need a Back button (Editor’s note: this is not a web-based application)

Product Manager: Seems simple enough, do you envision the Back button being used frequently?

User: Oh yes!  Often times we need to go back and reference or correct an order that we worked on up to two hours ago.  We move through the orders so fast we can’t always remember the order number or customer so a search is not an option, so we need to go back through our previous orders.

Product Manager: Okay, I understand the problem but rather than a back button, how about having the ability to easily show the history and the user can see all the previous orders and go directly to that order.

By asking one more question – digging deeper into the why – I was able to fully understand the pain better and offer a better alternative than a simple Back button. This is similar to the Chrome and Firefox feature that allows you to see the history by holding down or right-clicking the Back button.  It is easy to see how clicking through the Back button in a linear fashion is inefficient when the page or order you need was more than a few clicks back.  I’m sure this is why the Show History option was implemented in these browsers.

In a similar vein, but all together a different market, I was reading my August 2015 issue of Bicycling magazine, and in particular an article titled “How to get $h!t Done” which is about Lisa Nutter, the First Lady of Philadelphia. On top of being a serious cyclist, the First Lady is a huge advocate to make riding more accessible.  In the article she states:

The language used to describe bike infrastructure is becoming a barrier to talking about what people really desire.  People aren’t saying, “We want bike lanes.”  They’re saying, “We want safe ways to get here and there.”  We have to listen to the way people talk about cycling and engage them where they are, not where we want them to be.

I completely agree with what the First Lady is saying, however, I think that most people do indeed offer specifics on what they think the right solution would be, in this case bike paths.  Product Managers need to understand what they really want which is a safe way to ride in city streets.  Bike paths may be part of the solution but not necessarily all of it or maybe not even the highest priority, maybe it means additional or improved crosswalks.

So the takeaway here is very simple, always dig into the problem, keep asking questions, discover the pain and in doing so you will find what the best solution is.


Book Review: Writing Effective Use Cases

Writing Effective Use Cases Front Cover Alistair Cockburn is a well-renowned expert on agile development and use cases; his book Writing Effective Use Cases is a “must read” for all product managers.  There are professional books that you read, then put aside and sometimes you might refer to them.  Other books become part of your core reference library, never far from your reach, dog-eared from frequent reading, and filled with highlights and underlines – this is one of those books. 

For someone who has never written a use case, this is an excellent starting point, covering all you need to know about use cases to be successful.  For those that have written use cases, I am confident that you will find many new valuable nuggets of information that will help you in your job.  The book is manageable in length (270 pages including appendices and index) and very practical with many examples of uses cases throughout (including examples of bad ones).  The most valuable aspect to the book is Cockburn’s professional advice and tidbits that he sprinkles throughout the book.  Anyone who is familiar with Alistair Cockburn’s work knows that he has a great deal of experience, and it shows in this book.  This book is short in theory and long in real-world examples.

Cockburn refers to use cases as “scaffolding” that connects various pieces of the project, which is very true.  Use cases are crossed linked to requirements, user interface designs and test plans, creating a traceability matrix throughout the lifecycle of the project.  Cockburn dedicates a chapter to how use cases fit in the overall process.  Managing the entire body of use cases is just as important as writing them.

A big part of any product manager’s job is time management, and Cockburn addresses this in the book.  It is not feasible to write detailed use cases right from the start, and it certainly cannot be done for all of the potential uses cases.  Cockburn stresses the importance of “warming up” with use case briefs or narratives, and then working towards more detailed, fully dressed use cases.

I like how Cockburn distinguishes between requirements and use cases – this is an important concept for product managers to understand.  In short, use cases really are requirements.  Properly written, use cases describe the behavioral requirements.  However, with that said, use cases do not deal with all requirements such as the non-functional ones (external interfaces, performance criteria, documentation standards, etc.).

For those product managers that already have their own format or preferred method for use cases, Cockburn provides many examples of different use case styles.  He is quite flexible in this regard, understanding that use cases are, “fundamentally an exercise in writing prose essays, with all the difficulties in articulating good that comes with prose writing in general”.  What Cockburn is very insistent about is that the use cases must be easy to read, short and clear for all stakeholders to understand.

There are other excellent books on use cases (Use Case Modeling by Bittner and Spence is one I would also recommend), however, at the end of the day, a product manager needs to adopt one standard and run with it.  Cockburn’s book fits this bill and more.  I would highly recommend this book for new or experienced product managers.