The Build Trap
"Move Fast and Break Things"
This mantra seems to have taken the startup world by storm since Facebook made it their motto a few years ago. I have heard countless CEOs say it's part of their company culture, something that makes them innovative. You can even find some enterprises repeating this phrase to their employees at an attempt to channel startup culture.
There is a serious flaw with "Move Fast and Break Things", and it's that most companies see this as an excuse to stop analyzing what they intend to build and why they should build it. Those companies get stuck in what I call "The Build Trap".
It usually happens like this:
After finding some kind of product/market fit and traction with customers, we raise money from investors and hire a team of developers. Now we also have a bunch of important people who want to know what we're doing with their money. We want to show them how hard we're working, so let's make sure we're constantly building and releasing. Right now the developers are building Version 1, but once that's out what is next? Developers can't just stop working; we need something for them to do.
Product Roadmap meetings are held and ideas are generated on what we could do build to increase our KPIs - drive registrations, more sales, etc. Ideas come up from Product Managers or Executives, and some seem like a good bet so we schedule them. When the time comes to build the product, we design and build the whole thing based off the ideas that we had originally.
This cycle continues until the company grows from 100 people to 500 people to huge corporations, where it becomes part of the norm and the way we do things.
And thus we fall into The Build Trap. The problem with this cycle is that our first ideas are not always our best. When we immediately jump into build mode, we don't have much information on how our customers will respond to these products, what they would want to do with them, or if they even solve a problem. Our design or product decisions are not based on fact, but on our best guesses. Most of those guesses are wrong.
In order to base our decisions on fact, we need to take a step back and focus on THINKING more than BUILDING. Thinking gets neglected in companies because the act of thinking doesn't directly produce something we can give to customers. Only building does that. This mentality is evident in our everday work lives. Look at the way we measure the success of our workers and our companies. All of our metrics are geared towards production of code or product. Even Agile standups - "What did you do today, what did you do yesterday?" If you haven't delivered your items on time, you get penalized. If you have delivered your items on time, you get rewarded. If you can produce more than another person, you get promoted.
This is a very flawed system because the amount of things we produce is no guarantee of a successful company. Building is the easy part of the product development process. Figuring out what to build and how we are going to build it is the hard part. Yet, we are only allowed a few days or a week at the beginning of each sprint for designing and speccing this out. We completely neglect research and experimentation in favor of spending more time writing code.
If we want to create better products and get out of the Build Trap, we need to change our mentality. This is true for both startups and large corporations. We need to give ample time throughout the product development process for exploring problems, thinking of solutions, and testing those solutions with our customers. Employees should be rewarded for solving problems, learning, and creating products our customers want, not how much code they can produce. "What have you delivered today?" has to become "What have you learned about our customers or our business, and how can we use that to our advantage?" When we change our conversations to strategic thinking instead of production, we can create a culture that is truly innovative and competitive.
So the next time someone at work says "move fast and break things", ask them "what are we learning by doing so?"
