If your company makes four products, it really makes five. If it makes 12, it makes 13. Even companies that make just one thing actually make two.
The secret product? The company itself. Your company is a product. Who are its customers? Your employees, who use it to do their jobs.
Since your company is the product that makes all of your other products, it should be the best product of all. When you begin to think of your company this way, you evaluate it differently. You ask different questions about it. You look at improving it constantly, rather than just accepting what it’s become.
How does the company interface with its users? Can employees figure out how to access everything it offers? Does it do what you’d expect if you did this or that? Does it get in the way sometimes? When does it frustrate people? What are its notable features?
These are the kinds of questions you’d ask about any other product you make. Start looking inward, and ask the same about your organization.
Basecamp has been in business for 17 years, but I started thinking about it as a product only a few years ago. Once I put on this lens, I started to see it in a new light.
Just as many companies usability-test their products with customers, I started usability-testing our company’s methods with our employees.
As the number of people who work at Basecamp has grown, I’ve noticed places where we could use more features, like management, structure, and guidelines. I’ve also noticed places where we’ve overengineered ourselves and should pull back.
I’ve witnessed how various methods of communication can result in a number of outcomes. For example, introducing something new to a group in person, which seems like the most humane way to share information, is often met with a series of random questions that can cause confusion. It turns out that writing a thorough post explaining new ideas often leads to more productive discussions later on.
One particular goal we’ve been focused on lately is removing dependencies. Whenever you need something from someone else before you can move forward, it’s a dependency. We believe dependencies slow people down. We want people to be more independent, because that will keep them moving forward.
A case in point: When developing software on different platforms, we noticed our desktop teams and our mobile teams were waiting on one another too often. No one ever told them to do this, but over time, it became more likely one wouldn’t move forward until the others were finished with what they were doing. They were aiming for feature parity on every platform.
But really, there was no reason for any of these teams to wait for the others. So we gave them permission not to. We told them the mobile apps could ship with simplified web-based views that the desktop teams had already made. Then, if the iOS or Android teams wanted to make those views even better on phones, they could take that on as a separate project whenever they had time. Each team could make independent decisions. This tweak has allowed all of the teams to flourish on their own.
A company can encourage dependence or independence, just as a product can encourage a specific behavior. A drawing app can make it easier to draw a perfect circle, or it can make it easier to sketch something rougher that resembles a circle. It’s up to the product designer to decide the default behavior of the product. The same thing is true for those who make and run companies. How do you want to design yours?