Box opens up about the company’s approach to innovation
Most of us never really stop to think about how the software and services we use on a daily basis are created. We just know it’s there when we want to access it, and it works most of the time. But companies don’t just appear and expand randomly, they need a well defined process and methodology to keep innovating or they won’t be around very long.
Box has been around since 2005 and grown into a company on a run rate of over $500 million. Along the way, it transformed from a consumer focus to one concentrating on enterprise content management and expanded the platform from one that mostly offered online storage and file sharing to one that offers a range of content management services in the cloud.
I recently sat down with Chief Product and Chief Strategy Officer Jeetu Patel . A big part of Patel’s job is to keep the company’s development teams on track and focused on new features that could enhance the Box platform, attract new customers and increase revenue.
Fundamental beliefs
Before you solve a problem, you need the right group of people working on it. Patel says building a team has a few primary principles to help guide the product and team development. It starts with rules and rubrics to develop innovative solutions and help them focus on where to invest their resources in terms of money and people.
Graphic: Box
When it comes to innovating, you have to structure your teams in such a way that you can react to changing requirements in the marketplace, and in today’s tech world, being agile is more important than ever. “You have to configure your innovation engine from a team, motivation and talent recruiting perspective so that you’ve actually got the right structure in place to provide enough speed and autonomy to the team so that they’re unencumbered and able to execute quickly,” Patel explained
Finally, you need to have a good grip on the customer and the market. That involves constantly assessing market requirements and looking at building products and features that respond to a need, yet that aren’t dated when you launch them.
Start with the customer
Patel says that when all is said and done, the company wants to help its customers by filling a hole in the product set. From a central company philosophy perspective, it begins with the customer. That might sound like pandering on its face, but he says if you keep that goal in mind it really acts as an anchor to the entire process.
“From a core philosophy that we keep in mind, you have to actually make sure that you get everyone really oriented in the company to say you always start from a customer problem and work backwards. But picking the right problem to solve is 90 percent of the battle,” he said.
Solve hard problems
Patel strongly believes that the quality of the problem is directly proportional to the outcome of the project. Part of that is solving a real customer pain point, but it’s also about challenging your engineers. You can be successfully solving the low-hanging fruit problems most of the time, but then you don’t necessarily attract the highest quality engineering talent.
“If you think about really hard problems that have a lot of mission and purpose around them, you can actually attract the best team,” he said.
That means looking for a problem where you can add a lot of value. “The problem that you choose to spend your time solving should be one where you are uniquely positioned to create a 10 x value proposition compared to what might exist in the market today,” Patel explained. If it doesn’t reach that threshold, he believes that there’s no motivation for the customer to change, and it’s not really worth going after.
Build small teams
Once you identify that big problem, you need to form a team to start attacking it. Patel recommends keeping the teams manageable, and he believes in the Amazon approach of the two-pizza team, a group of 8-10 people who can operate on..well…two pizzas. If the teams get too large, he says it becomes difficult to coordinate and too much time gets wasted on logistics instead of innovation.
“Having very defined local missions, having [small] teams carrying out those local missions, and making sure that those team sizes don’t get too large so that they can stay very agile, is a pretty important kind of core operating principle of how we build products,” Patel said.
That becomes even more important as the company scales. The trick is to configure the organization in such a way so that as you grow, you end up with many smaller teams instead of a few bigger ones, and in that way you can better pinpoint team missions.
Developing a Box product
Patel sees four key areas when it comes to finally building that new product at Box. First of all, it needs to be enterprise grade and all that entails — secure, reliable, scalable, fault tolerant and so forth.
That’s Job One, but what generally has differentiated Box in the content management market has been its ease of use. He sees that as removing as much friction as you can from a software-driven business process.
Next, you try to make those processes intelligent and that means understanding the purpose of the content. Patel says that could involve having better search, better surfacing of content and automated trigger events that move that content through a workflow inside a company.
Finally, they look at how it fits inside a workflow because content doesn’t live in a vacuum inside an enterprise. It generally has a defined purposed and the content management system should make it easy to integrate that content into the broader context of its purpose.
Measure twice
Once you have those small teams set up with their missions in place, you have to establish rules and metrics that allow them to work quickly, but still have a set of milestones they have to meet to prove they are on a worthwhile project for the company. You don’t want to be throwing good money after a bad project.
For Patel and Box that involves a set of of metrics that tell you at all times, whether the team is succeeding or failing. Seems simple enough, but it takes a lot of work from a management perspective to define missions and goals and then track them on a regular basis.
He says that involves three elements: “There are three things that we think about including what’s the plan for what you’re going to build, what’s the strategy around what you’re going to build, and then what’s the level of coordination that each one of us have on whether or not what we’re building is, in fact, going to be successful.”
In the end, this is an iterative process, one that keeps evolving as the company grows and develops and as they learn from each project and each team. “We’re constantly looking at the processes and saying, what are the things that need to be adjusted,” Patel said.