Three Kings Monument, Chiang Mai Thailand

7 Ways to Use the Rule of Threes to Build Great Products

Great things come in threes. Take, for example, Christmas, Hanukkah and Kwanzaa. Or, Harry, Hermione and Ron. Or, the primary colors.

The rule of threes states that things that come in threes are funnier, more satisfying, or more effective than other numbers of things. (It is from the internet, so it is true.)

Threes are powerful. Here is how to harness the power of threes to create great products.

Teams — roles, motivation & accountability

A great team is one where roles are clearly defined and everyone is motivated to do their best work.

Team composition will depend on need, but a team is at least 3 people. I’ve worked on 2-person product teams, and while it is possible, the dynamic can easily devolve into offense and defense. Having a third person creates balance.

Furthermore, there is usually just too much work to do for only 2 people. Three people is the perfect size to be agile: you are small enough quickly get on the same page, and large enough to divide labor effectively.

Each team member has tasks and large chunks of work that she is responsible for, but more than that, each team member should be accountable for some major aspect of the product such that they get the deciding vote on it.

Goals— long term, short term & even shorter term

Setting your own product goals can be daunting. You want to aim for something lofty, but also attainable. Being in the red all quarter is never fun. In fact it can demoralize your team and slow development.

But setting goals doesn’t have to feel like a burden. Here is a simple formula:

  1. Identify a core business theme
  2. Find a metric that is an early indicator that you will impact that theme
  3. Tie it all together

The right business core theme will depend on the company’s stage of growth, and typically is one or a combination of the following: NPS, conversion, revenue.

These business themes track to long-term metrics, which make them challenging to track iteratively.

For example, if I want to impact 30-day day conversion, which my company tracks across all product lines and which accounts for the majority of all paid conversions, I would need to wait two months to get just one treatment cohort, at which point I am already committed to product direction, not to mention two-thirds of the way through the quarter.

So, tracking against the long term metrics would be death to agile development.

Instead, you need to find an intermediary metric, or a marker of the change you expect to see in user behavior on the way to impacting the core business theme.

In this way you need to set a long-term goal mapped to company goals, a short-term goal mapped to your specific product, and an even shorter-term goal that you can measure very frequently (see more in the section on Time).

Story — past, present & future

Determining product direction can be be circuitous and involve a lot of divergent thinking. But, once you’ve converged on one goal, you need to make it digestible to your audience, meaning your team and stakeholders.

A good story covers the past, touches on the status quo, and then builds a vision for what the future will look like with your product in the world. It includes key data that supports your point, but is not overly complicated.

In addition to the narrative story, build out models to show the quantifiable impact of product work.

Models makes it extra clear to stakeholders the ROI of the product, which will helps guide strategic decisions about time spent on it.

Time — months, days & timezones

The longer it takes to develop a product, the more impact it needs to justify. Keeping scope and time limited is key to driving success without going over budget. Unless you are pioneering something completely new, three months is all you need to identify goals, and rapidly iterate to success.

One limitation to building quickly is time to gather data. It is important to constantly measure your test to make sure you are on the right track so that you can course correct and so that you can keep your team (and stakeholders) happy by showing them that the work you are doing is effective.

But, if you want to measure any metric that accumulates over time, you will need to wait typically double that timeframe in order to have a cohort who saw the treatment for the full amount of time. Waiting this long sincerely slows down product development.

Instead, you need a much shorter time frame.

You can redo your analysis linking the top level business goal to the product goal using a shorter time frame, like one day, and use that proxy metric to make quick decisions mid-development.

NOTE: When you are looking at short timeframes and with an international user base, time zones start to affect your data, so you need a time buffer on either end.

User Research — anecdotes, coincidences & patterns

Great products are built with the user in mind, and often, with the user at the table.

User interviews should be done heavily at the beginning of product development to really understand who you are building for, what their pain points are, and how you can best solve them.

User testing should be done anytime you have a new prototype, in conjunction with interviews or as stand-alone sessions.

While both types of user research are vital, they are also incredibly time consuming, and so you can’t do them with abandon. You also need to know when you have an insight that you can actually act on.

This is where the rule if threes shines yet again.

  • If you hear something from a customer once, consider it an anecdote. Note it, but keep going.
  • If you hear the same thing twice, you should perk up, but don’t get too excited. It could just be a coincidence.
  • However, if you hear the same thing three times, that is a pattern. It is time to stop interviewing and/or testing for that hypothesis and start building to answer it.

NOTE: You can only reliably follow this rule if you are talking and testing with users who are part of our target audience.

Iterations — V1, V2 & V3

Consistent shipping not only keeps your engineer happy, your product less buggy, and your customers up-to-date, it also lets you build to collect data, giving you more information to make good decisions.

I’ve found that aiming to ship every two weeks, for 6 versions total, works well.

Least you think this isn’t following the rule of 3 pattern, every integer version (V1, V2, V3) is a fully built new feature, based on an insight from talking with users and digging into data. Every half version (V0, V1.5, V2.5) is an early shipment to test an idea and gather more data.

Each iteration is a chance to address any bugs that have surfaced and continue to message what is new to users.

But most importantly, shipping continuously and with data gathering in mind, helps answer big question that about the product and validate that it works before putting more time and resources into it.

Retrospectives — Start, Stop & Continue

Team retrospectives let you air things that went well for the team during the quarter and those that we could improve. It is helpful to have someone who was not directly involved in the team to facilitate the Retrospective so that as a neutral party.

One model that works well for Retrospectives is Start, Stop and Continue because it puts the focus of the retrospective on learning from what went well and what did not, rather than getting caught up in the details.

Team members each spend a few minutes writing down things that they want to Start doing, Stop doing, and Continue to do. You can use a new sticky note for each thought and then post the notes in groupings on a whiteboard to see patterns. Typically, team members reflect on similar success and challenges, but it is helpful to see how each person internalizes the situation and reflects on it.

Ideally, these are done every few weeks to help teams refine their process.

Building great products

At the top of this article, I claimed that great products can be built using the rule of threes for teams, goal setting, story telling, time constraints, iterations and retrospectives. But, what is a great product?

A great product does not need to win an awards or disrupts an industry. A great product is simply one that achieves its goal. It is a product that helps users achieve something that they want to do, and helps grow the business at the same time.

So, why the Rule of Threes? It is just one of many frameworks for product development. However, I am partial to it because it is grounded, balanced, and, most importantly, it reminds us that no great product is built on any one person, concept or principle.