Using Product Principles to Guide Your Decision-Making

How should a product team decide what to build? The options are (theoretically) endless, but your organization’s resources are limited. And as a company scales, the formal decision-making process only accumulates more and more red tape. 

If a product team has to take every product decision all the way to the top of the corporate hierarchy for approval, they’ll lose agility, efficiency, and valuable time. That means product teams need autonomy and must be empowered to make their own calls when it comes to the product. To do so effectively, however, they need a decision-making framework.

At Box, one of the top file-sharing and cloud content management companies, this framework takes the form of product principles. Last month, Box’s CPO Jeetu Patel presented at the ProductCraft Virtual Conference and shared the product principles they’ve codified. If a feature idea doesn’t align with these principles, then Box does not pursue it. That doesn’t mean that the idea is bad, or wouldn’t drive revenue — it means that it isn’t right for Box.

During his session, Jeetu went through all seven of Box’s product principles and the trade-offs the company makes to stay true to them. 

Product principle 1: Protect our customers’ data above all else

Versus: Focusing on revenue monetization

Jeetu said that it is both a “responsibility and a privilege” to be the stewards of their users’ data. And it’s business-ending if there’s a breach. 

The tradeoff? Expense.

Box has paid a premium to have multiple data replications for disaster recovery. They even have plans for nuclear war, asteroid strike, and other worst-case scenarios. 

Product principle 2: Make content infinitely better when in Box

Versus: Creating a homogeneous experience across repositories

The Box team strongly believes that if users choose to store their content within Box, then it should accrue value. As a result, they try to build features that compound the value of their content. One example of such a capability is allowing users to preview files that are classified as malware without opening them.

The tradeoff? Transferability.

The more customized the Box platform becomes, the harder it is for users to move their files between providers without losing key capabilities.

Product principle 3: Be insanely simple

Versus: Be highly functional while sacrificing simplicity

Box values simplicity over building a lot of features. But creating a “simple” user experience is extremely difficult, and requires lots of iteration, A/B testing, design, etc. Nevertheless, the Box team considers this to be worth it. In fact, when users told them that syncing was taking too much time/space, they created a filesystem from scratch rather than building out small efficiencies. This took years and an acquisition to accomplish, but the result was simplicity and ease-of-use. 

The tradeoff? Feature density.

According to Jeetu, the product team at Box is willing to sacrifice building out a high number of features to keep the product as user-friendly as possible.

Product principle 4: Build horizontal software for the masses

Versus: Specialized vertical solutions

Box is for everyone! Users might work at three-person companies or huge global enterprises. They might work in healthcare, software, or retail. And each user gets the same product — they don’t build features simply to please one big customer. Any new feature needs to have appeal across industries. An example is their recently-released watermarking feature.

The tradeoff? Industry specialization.

Many companies out there have become extremely successful by focusing on one specific vertical. However, that’s simply not Box’s strategy.

Product principle 5: Focus on building out network effects

Versus: Solutions for single enterprise instances

A “network effect” is when a tool becomes more valuable as more and more people use it. For every person who uses Box, it’s more valuable to them when more people use it. This is due to the inherent properties of Box (sharing content, for example — this becomes much easier if multiple people have the tool).

The tradeoff? Tech scalability issues (and time).

Strong network effects can produce exponential increases in users and engagement, so you must be sure that your product can handle the load.

Product principle 6: Think 10X

Versus: Being incrementally better and executing a fast-follow strategy

Box doesn’t build features just to “check a box” — they want to provide a step-function increase in value with every new thing they put into market. These value increases are what make users switch to your tool from another. They’re your differentiators. On the day the iPad first launched, for example, Box released its iPad filesystem capability. They were the only ones who had this, which drove new iPad users to their platform.

The tradeoff? Quick iteration and releases.

Box doesn’t release updates and new features on a fast cadence. Each one takes months of planning and building to get just right.

Product principle 7: Partner deeply. Don’t underestimate the power of neutrality

Versus: Trying to own the full stack

Jeetu said that if you can’t be 10x better at something, partner with someone who can. Don’t try to be all things to all people. Box will ever partner with competitors if they’re also part of their customers’ stack.

The tradeoff? Loss of neutrality.

For many customers, Box is deeply embedded within a network of complementary tools. It can’t stand fully alone but is also more difficult to remove due to key dependencies.

Creating a set of product principles is no easy task and requires input from a wide range of stakeholders. Don’t select them lightly — they’ll inform every feature release and product decision.