Why you should treat your company as a product
Outcome-driven leaders view organizations as something they can design, test, and improve. Like a product.
Welcome to the third article in the series about building outcome-driven organizations and getting results from OKR. If you haven’t already read the previous articles, I recommend starting there:
At the end of this article, you’ll find a list of questions to help you put the article into practice, and a reading list with additional links.
This post is also available in Portuguese for my friends in Brazil.
Outcome-driven leaders define success based on outcomes, but they don’t stop there. They also treat organizations like products—something they can design, test, and improve.
Steve Jobs was the ultimate example of a leader who managed the company as a product. When asked about which product he was most proud of, he replied:
You know, making a product is hard, but making a team that can continually make products is even harder. The product I’m most proud of is Apple and the team I built at Apple.
Outcome-driven leaders treat each element of the organization as a “product feature” that exists to help the organization succeed.
These “organizational features” include things like processes, metrics, rituals, reports, structure, data, tools, skills, and behaviors.
Paraphrasing Dharmesh Shah, co-founder & CTO of HubSpot:
Every company builds two products, one is the product they build for their customers, and the other is a product they build for their team
Your company’s culture and operating model together form the product you build for your team. They exist to help the great people you have do great things for your customers and your company.
In this article, we’ll discuss what it means to treat your organization as a product and the mindsets and behaviors that prevent people from doing that.
Outcome-driven leaders intentionally design how the organization operates
All companies have a culture and an operating model, whether they were intentionally designed or not.
The difference is that outcome-driven leaders intentionally design each element of their companies. They deliberately evolve their culture and ways of working to facilitate achieving outcomes.
As tech blogger John Gruber points out, Steve Jobs was very intentional about how Apple should work:
The same thought, care, and painstaking attention to detail that Steve Jobs brought to questions like “How should a computer work?”, “How should a phone work?”, “How should we buy music and apps in the digital age?” he also brought to the most important question: “How should a company that creates such things function?”
Outcome-driven leaders regularly ask questions such as:
What behaviors do we want to reinforce and encourage in people? Which ones do we want to inhibit?
What factors are hindering our performance? Which ones are helping?
How can we create an environment where teams can perform at their best?
Let’s take a deep dive on an even more powerful question.
Will it help achieve our desired outcomes?
Ben Hunt-Davis is a leadership coach who won a gold medal as part of the British rowing team in the 2000 Olympics. His key principle is, “Will it make the boat go faster?” Meaning, will this help the organization succeed?
Outcome-driven leaders do something similar. They challenge everything their organizations do—or don’t do—with the question: “Will it help achieve our desired outcomes?”
If it helps accomplish their intended outcomes, they keep doing it. If it doesn’t, they try something different.
This philosophy applies to what they work on (product features and projects) and also to how they work (their operating model or ways of working).
Each element of your company’s operating model or culture exists for a reason—helping the organization achieve its mission and desired outcomes.
For example, many companies realized that if they wanted to adopt empowered teams, they had to change their approaches to incentives and goals.
Software engineering coach Doc Norton jokingly pointed out how companies sound when they fail to do that:
We simply ask that you be innovative without mistakes while working as a team to achieve individual performance goals.
Outcome-driven leaders are willing to change or abandon anything that is not helping their organizations make a difference. They are also ready to unlearn old mindsets and behaviors.
This way of thinking is not new. One hundred years ago, Henry Ford preached something similar:
Be ready to revise any system, scrap any method, abandon any theory, if the success of the job requires it.
This flexibility enabled Ford to achieve a productivity miracle with his continuous-motion assembly line, decreasing the worker hours required to produce a Model T car by nearly 90%.
Outcome-driven leaders work on two fronts at the same time
Here’s another way to view this: outcome-driven leaders work on two fronts at the same time. They work on achieving their intended outcomes, but also on optimizing the organization to achieve outcomes (hat tip to Marty Cagan for the expression).
An old saying helps us understand what that means: “If I had five minutes to chop wood, I would spend the first two and a half minutes sharpening my axe.”
Following this analogy, outcome-driven leaders balance two dimensions:
Achieving outcomes (“Chopping wood”): Work to accomplish their intended outcomes using current practices and workflows.
Optimizing the organization to achieve outcomes (“Sharpening the axe”): Work to improve how the organization operates, evolving its culture and ways of working to facilitate the achievement of outcomes.
Steve Jobs hinted at those two fronts when talking about “making a product” (chopping wood) versus “making a team that can continually make products” (sharpening the axe).
Successful companies use OKR to sharpen the axe
You may be wondering how OKR fits into this discussion.
I’ve been helping companies around the world adopt OKR and outcomes since 2014. After training and mentoring thousands of people, I noticed a clear pattern separating the companies that succeed with OKR from the rest:
Successful companies use OKR to sharpen the axe, evolving their culture and ways of working.
But the vast majority of people make OKR fit their old way of working. Like that popular definition of insanity, they keep doing the same thing over and over while expecting different results.
OKR can be a powerful tool to help build an outcome-driven culture and optimize your organization. But it can also help keep things exactly the same. It all depends on how you use it.
Some people refer to the two fronts above as running the business vs. changing the business. But according to research, most companies make limited changes to how they work, and the result is that 70% of transformations fail.
I’ve repeatedly encountered an ironic example of this insufficient axe sharpening while working with clients.
Many companies have invested in “transformation,” all claiming to use OKR, of course. But instead of using these investments as a way to become more outcome-driven, most organizations focus on meeting due dates rather than outcomes.
Often the goal is simply to do something like “move to the cloud by the end of the year.” It doesn’t matter if this project made a difference or not, only that it was completed on time.
Many transformation initiatives implicitly assume all projects will be successful. Instead of doing discovery and quickly testing ideas, they rely on projects that don’t deliver value for 12–18 months and rarely measure their outcomes.
Look closer and you’ll see these companies are using “Agile” techniques to deliver waterfall projects—there’s nothing close to continuous delivery of value.
This whole situation is a classic case of the know-it-all mindset, where we believe we have all the answers. The hidden assumption is, “There’s no need for measuring or experimenting, we know what we’re doing.” There’s not much transformation there.
This issue isn’t limited to traditional corporations. Many younger tech-powered companies do similar things.
We have to remember that most organizations are not ready for outcomes. If you want to benefit from being outcome driven, you must change your organization at a fundamental level—superficial adjustments won’t do.
You can make progress in gradual steps, but you have to take those steps.
The hidden reasons why people fail to sharpen the axe
Transforming is hard. Sometimes leaders resist it or don’t know what to do.
But there are also four hidden reasons why people fail to sharpen the axe:
Operating on autopilot: People often go through the motions instead of being intentional about what they want to achieve and how they work.
Fixed work mindset: Many people see their organization as something fixed that can’t be changed instead of a product that can be designed and improved.
Rework phobia: Sometimes people resist sharpening their axes because they hate rework (i.e. making changes to something they’ve already worked on), even when they know it’s good for them.
Lack of perceived agency: Some people feel like they're just a cog in the machine and believe there’s nothing they can do.
Let’s discuss each of these in more detail.
People often operate on autopilot
Most people are not intentional about how they work. We all have a tendency to operate on autopilot, doing what we’ve always done.
When we do that, we go through the motions without questioning what we want to achieve or how we work.
People often overlook a basic question: What problem are we trying to solve?
This question is so cliché that it’s listed in books about how to “look smart” at work. And yet, we skip it when we operate on autopilot.
One consequence of not asking that question is that people often don't know why a process or metric exists.
As Amazon’s founder Jeff Bezos points out:
It’s very common, especially in large companies, that they’re managing to metrics that they don’t really understand. They don’t really know why they exist, and the world may have shifted a little and the metrics are no longer as relevant as they were when somebody invented the metric 10 years earlier.
Bezos again:
You have to be on alert for that. You have to know, “Okay, I don’t really care about this metric. I care about customer happiness and this metric is only worth putting energy into and following and improving if it actually affects customer happiness.”
It’s extremely easy to lose sight of the difference we want to make. We go through the motions without questioning why a metric or process exists.
The solution is to start by clearly defining our intended outcome, why it’s important, and the constraints for achieving it.
Metrics are a critical “product feature” of your organization, but people don’t discuss them enough when setting OKRs. They may discuss the numbers, but they don’t discuss the metrics.
There’s a lot of “last month this metric was 10, now it’s 12,” but not enough “is this the right metric?”
There's often little discussion about current processes or practices, even when they are clearly broken.
Let’s look at an example that can feel very tactical but has a huge impact: meetings.
What if you managed meetings as a product?
Research shows that executives spend an average of nearly 23 hours a week in meetings, and yet everybody hates them.
As product development thinker John Cutler points out, if meetings were a product, no one would buy or renew. They have no product-market fit—people show up, get no value, and complain. I doubt you could find a product with worse customer satisfaction scores.
What if you intentionally designed and experimented with your meetings?
Companies like Dropbox and Asana found that each employee could save 3 to 11 hours a month by canceling or redesigning low-value meetings.
Companies like Amazon and Stripe are known for having reimagined meetings. All meetings start with attendees reading a document, which is both faster and allows for deeper debate than watching someone present slides.
What if you took this idea beyond meetings and intentionally designed other organizational features?
Most people see organizations and teams as something fixed
Outcome-driven leaders see organizations like products they can design, modify, and improve, but that is radically different than how most people think.
Psychologist Carol Dweck popularized the idea that some people have a fixed mindset and see their abilities as fixed traits they can’t change. Dweck’s research is about individuals, but I’ve noticed people often apply a similar mindset when thinking about work.
People with a “fixed work mindset” see the way their organization operates as something that is mostly carved in stone and can’t be changed. Many individual contributors see their teams in a similar way.
For example, when I talk to leaders from large or mid-sized companies, many complain that they can’t use OKR or focus on outcomes because they have too many dependencies between teams.
The traditional solution is to “manage” those dependencies—spend a ton of time coordinating work among multiple teams.
This approach not only slows everything to a crawl, but also makes it very hard for teams to take ownership over an outcome, as everything depends on everyone else.
And yet, executives with a fixed work mindset believe there’s nothing they can do.
The folks at Amazon had a different mindset. Faced with the same problem, they realized there was no law saying every project had to involve so many separate teams.
Around 2002, Jeff Bezos and the other executives grew tired of managing dependencies and decided to eliminate them instead.
Amazon famously invested in drastically reducing dependencies by making major changes in how it built software and adopting a new software architecture, embracing APIs1.
The company also reduced dependencies by changing the team topology—the way organizations split work among different teams, including their structure and scope.
The goal was to create what Amazon calls separable teams, teams that need minimal coordination with others and have a high degree of autonomy and ownership over their work.
The fixed work mindset affects executives and individual contributors alike
The fixed work mindset is an equal opportunity condition, and it doesn’t discriminate—it affects executives and individual contributors alike.
Of course, there’s a limit on what teams and individual contributors can change in an organization. But people with a fixed mindset see the way their teams operate as something carved in stone—even things they could actually change.
The table below shares a few common examples of things people say when they see the organization as something fixed.
Pause for a second and ask yourself: have you ever said or thought similar things?
Some people hate rework, even when it’s good for them
Sometimes people resist sharpening their axes because they hate making changes to something they’ve already worked on—even when they know it’ll be good for them.
People who have worked on projects for a long time tend to develop rework phobia.
Rework phobia (noun):
Irrational fear or hatred of making changes to something you’ve already worked on.
The mistaken belief that all rework is bad and must be avoided at all costs.
People with rework phobia often say things like, “We can’t change our OKRs now, we’ve spent so much time on them!”
They also say, “We’ve worked hard to define our strategy, it’s frustrating to learn it’s wrong. If we change it now, people will think we did a bad job.”
Another common one is, “We can’t set quarterly OKRs because we won’t ship anything in the next nine months. But we can’t change our projects now because we’ve spent so much time planning them.” (I’ve decided to mention this issue twice in this article because it is so widespread.)
In the project world, rework is always bad because it means someone made a mistake and you have to do the work again. You may even be blamed for something that wasn’t your fault.
The same happens in manufacturing, where rework is the process of correcting defective work items. Projects and manufactured goods are supposed to be one-time endeavors: do things once and you’re done.
But products are never “done,” they continue to evolve. Working on a new version of something is natural in the product world.
People at Netflix don’t say, “We’ve spent so much time on the recommendation feature, we can’t change it now!” They keep iterating the feature.
The outcome-driven mindset involves understanding that you can’t know everything in advance, but you can learn. Rework doesn’t always imply a mistake—it can happen because you’ve learned something new.
As software development guru Kent Beck points out:
The only way it’s all going to go according to plan is if you don’t learn anything.
There’s good rework and bad rework
Outcome-driven leaders understand the difference between good rework and bad rework.
Good rework is intentional and involves continuous learning and improvement. For example, good rework happens when we learn new things, enhance our products, adapt to changes, or use iterative development to improve and refine our product at each cycle.
Bad rework is unintentional and comes from poor practices. For example, bad rework happens when we don’t align on a clear outcome, change priorities often, have to fix the same issues repeatedly, or don’t do discovery and end up building things nobody wants.
I’m not saying you should spend all your time rewriting your OKRs or redefining your strategy. You need to balance optimizing your organization with achieving outcomes.
If you spend all your time “sharpening your axe” without “chopping any wood,” you’re doing it wrong.
You have more agency than you think
Sometimes people feel they are just a cog in the machine, and there’s nothing they can do. I’ve felt that way, too.
But I want to close this article with a reminder that you have more agency than you think—even as an individual contributor in a massive company.
I remember an excellent story told by Teresa Torres. It goes something like this:
A team complained to Teresa that they couldn’t do proper product discovery because their company didn't allow teams to talk directly to customers. They were prohibited from interviewing end customers and believed there was nothing they could do.
Teresa asked the team, is there any rule against interviewing your competitor’s customers?
You can learn a lot by talking to people who aren’t your customers. You can learn about their needs, desires, and pain points with the product they are currently using.
Ideally, you should interview your own customers, too, but don’t let that stop you from learning.
You have more agency than you think.
Let’s put this into practice
We’ll be back soon with another post. In the meantime, the best way to put this article into practice is by discussing its main takeaways with your colleagues or friends.
Here are a few questions to help:
What would your work look like if you treated your organization or team as a product?
Challenge some things you do—or don’t do—by asking, “Will it help achieve our desired outcomes?” After asking the question, what would you change?
Are you spending enough time sharpening your axe?
Are you using OKR to evolve how you work or to keep things the same?
What organizational "features" are past their expiration date?
In what ways might you be unintentionally operating with a fixed work mindset?
Where are you resisting good rework? Are you falling prey to rework phobia?
Feel free to share your thoughts in the comments or email me.
Below, you'll find a reading list with the links mentioned in this article.
Special thanks to Marty Cagan for reviewing drafts of this article, and to Carlos Accioly and Melissa Suzuno for helping me edit and develop it.
Cheers,
Felipe
Reading list and links:
Big Think: Walter Isaacson on Steve Jobs’ Favorite Product: The Apple Team.
Lenny’s Podcast: Zigging vs. zagging: How HubSpot built a $30B company | Dharmesh Shah (co-founder/CTO).
Dharmesh Shah: Culture is a product you build for your people.
John Gruber: Resigned.
Ben Hunt-Davis: Will it make the boat go faster?
Benedict Evans: Office, messaging and verbs.
McKinsey: 70% of transformations fail.
Lex Fridman Podcast: Jeff Bezos: Amazon and Blue Origin
Harvard Business Review: Meeting Overload Is a Fixable Problem.
If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.
An API is a set of routines, protocols, and tools for building software applications and defining how software components should interact.