Seven Rules

This one sounds straightforward, but it is easy to lose your way. You could confuse this to mean that you should listen passionately to your customers and do whatever they ask. If you are a consultant, that’s perhaps good advice, but if you are building a product, it won’t satisfy your customers. Jeff Bezos, for example, often points to an obsessive-compulsive focus on the customer as the primary driver of Amazon’s success; however, how often do you hear Amazon doing exactly what customers ask for?

Focusing on the customer is only part of the solution. To delight a customer, you have to exceed their expectations and go beyond their imagination in what you deliver. The way you get there is an obsessive-compulsive focus on solving customer problems. The challenge is that the problems your customers want you to solve are very hard to identify. Sometimes, the real problem worth solving is buried behind a dozen other problems your customer won’t pay for but that are required to get there.

Other times, your customers will send you down the wrong path by pointing out problems they don’t have. That makes delighting the customer so hard, and you need to be ready to commit to the journey. Use your time with customers to listen intently and build empathy and understanding using the 5 Whys. Once convinced that you understand your customer’s problems, spend some time trying to prove yourself wrong and seek out people who disagree. The rest is on you, your intuition, and your willingness to commit and iterate.

There are no sacred cows — not your code, your business plan, your marketing strategy, or your product roadmap. If it isn’t working, it goes. But knowing what isn’t working takes an environment of high psychological safety, and to create one, you must also create an environment that seeks out feedback at every turn and is comfortable with negative feedback. You must be ready to listen without getting defensive and be mentally prepared if it is soul-crushing. You must learn to be very suspicious of positive feedback as well. The 5 Whys can help you here, but it requires discipline. This will not be easy, it takes practice, and you will not get it right on your first try. You very likely will get defensive, you will look for the exit, and you might very well convince yourself right there to give up — don’t!

My advice? Approach it as an out-of-body experience. You are not there, but your representative is, and they have no skin in the game. Their goal is to ask objective questions, get to the root of the issue, and learn as much as possible. You can be emotional later when it’s time to empathize and understand where the feedback was coming from.

So how do you know when you’re done? For this, you have to use real data, not intuition. Are your customers using your features as often as you think they should be? Survey them to find out how they feel, and ask them how much time and effort your product saves them. Observe what they actually do. When data and intuition disagree, trust the data until you have evidence to do otherwise. The most dangerous belief in any organization is that we know what our customers want. That belief persists long after it stops being true, because it is comfortable.

This style of recursive refinement is even more critical in an era where cloud providers, well-funded startups, and adjacent players are eating the world. I’m often asked if I fear that the product I’m building will one day be threatened by AWS. While I have many reasons why CloudZero is in a better position to delight its customers and deliver functionality that Amazon won’t, the real answer is, “Of course they are going to compete with me if I create something of significant value!” The counter to that competition is not a better moat. It is a relentless commitment to iteration driven by customer data. Believe it or not, you can move faster than AWS, but you cannot sit still. They (or someone else) will absolutely overtake you if you do.

Don’t be afraid to throw your solution out the window when your customers aren’t embracing it.

How do you know they aren’t embracing it? You could point to sales as the ultimate indication, but even bad products can make money in the short term. By the time you are really hurting, it might be too late to change course. The leading indicator of product failure is a lack of engagement, both from customers and from your team. The problem for startups is that founders are hopeless optimists, they build passionate teams, and no one wants to accept they might be wrong. The reflex will be to optimize the solution, market it harder, or wait for the market to catch up. That reflex kills companies.

To counter this, you must seek out and telegraph loudly to everyone you work with that you want critical feedback. When you get it, prove that you wanted it by resisting the urge to become defensive. If you aren’t getting pushback, something is wrong; be highly suspicious of positive feedback that isn’t backed by data. If product praise isn’t complemented with actual product engagement, you are fooling yourself in the worst possible way.

Commit to iteration (Rule 4), but don’t confuse commitment to a direction with commitment to a specific solution. If the solution isn’t working, change the solution. If the direction is wrong, change the direction. Nothing is sacred.

Less is more. This one is so hard to get right. Blaise Pascal was the first to observe this when he wrote, “Je n’ai pas fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte” — I have made this longer than usual because I have not had time to make it shorter. Since then, many similar quotes have been said throughout time, all with the same claim: To do less, one has to work harder. That work is crucial because less is more.

But why is less, more? This concept can be applied to almost all aspects of a business:

• Engineering: Every line of code is a liability.
• Sales: A smaller but more qualified pipeline will close faster.
• Marketing: The more concise your message, the easier it is to understand.
• Product: Fewer features, better focus, happier customers.
• Finance: Spend on only what matters. Show me your budget, and I’ll show you your priorities.

Enforce this by pushing the team to devote a certain percentage of time every iteration to refactoring. Refactoring is also an excellent opportunity to remove features that don’t delight. Be ruthless when refactoring and abandon the parts that your market won’t care about; stay committed to the parts that delight. As Steve Jobs said, “Focus is about saying no.”

Software, much like art, is also never finished, only abandoned.

Unlike art, great software and great software companies are always a team effort. Sometimes getting a team to commit, however, can be hard. Lots of opinions will (and should) compete for attention until a decision is made, but once that decision is made, you need everyone to commit. So how do you ensure that happens? You get religious about iteration.

You have likely heard the phrase “Disagree and commit,” something often attributed to Jeff Bezos or, more accurately, Andrew Grove. The idea is that disagreement and debate are welcome upfront, but once a decision is made, disagreement is put aside, and you commit. I think disagree and commit is a powerful concept, but its intentions are misplaced. Instead of focusing on what comes before the commit, along with the implied negativity of disagreement, it is what happens after you commit that is far more impactful. Effective teams don’t just disagree and commit. They iterate.

Don’t let perfect be the enemy of good enough, but never stop chasing perfection.

When a team understands that iteration is not just expected, it is required, commitment happens faster. You have removed the penalty for changing one’s mind, both for those who might have disagreed with the initial direction and also for those making the decision. When your team understands that it must commit and then iterate, you remove the pressure to get it right on the first try.

Be warned, however! Other parts of your business will claim victory the moment any customer appears delighted and push you to stop iterating. Don’t let this happen! The first signs of delight are often based on your customers’ perception of future value, not actual value, and you still have a ways to go.

If something you build has the great fortune of delighting someone, don’t stop there and abandon it. Stay committed and keep going. If it was worth doing, it’s worth refining.

Ego is the enemy of great work. It shows up everywhere — in the engineer who won’t refactor their own code, in the leader who resents a team that moved without them, in the org that runs like five separate companies because no one wanted to give up ownership. If you want to build something great, ego has to go.

Nothing is Sacred (Rule 2) demands that you seek out critical feedback and follow the data wherever it leads. Ego is what stops teams from doing either — it hears hard feedback as an attack, and it defends a failing solution because we built it. The discipline belongs to Rule 2; the humility to practice it belongs here.

A team that has shed its ego observes more, debates better, and catches what any one person would miss. When the data points to an uncomfortable place, that’s exactly when you have to be ready to act. The teams that can’t do that aren’t blocked by the data — they’re blocked by ego.

The same ego problem that shows up in individuals shows up in organizations as silos. Territorial thinking is just ego wearing a badge, and it kills teams quietly, long before it shows up in the numbers. Customers feel every seam, every dropped handoff, every “that’s not my problem.” It is your problem. Your win is my win. Your problem is my problem.

If you are a leader or manager, you have an equally important role to play. If you see other teams moving fast and find yourself resenting that they didn’t wait for your input, stop right there — that resentment is ego. It is also your responsibility not to wait for the ask. If you believe your team’s perspective will be critical to the mission, proactively give it. Don’t wait for an invitation. It’s We, not I.

No one is more empowered to solve your problems than yourself. If you are blocked, ask for help; if no one is listening, raise your voice; but if the job isn’t getting done, be ready to take matters into your own hands. The keyword here is decisiveness. No one will ever be upset with you for getting something done vs. nothing, in particular if you are working at a startup.

As your organization grows, you need everyone to embrace the idea that they are fully empowered to do whatever it takes to get the job done. The Agile development tenet of valuing working solutions over comprehensive documentation isn’t limited to engineering. Whatever your team’s focus, don’t wait. Just do it.

You might be thinking that embracing this philosophy will step on a lot of toes. If that’s true, you might be working for a company that does not have clear roles and responsibilities (always bad) or one that has intentionally chosen to limit the rate of change (sometimes good).

It also might mean you haven’t invested in figuring out how to get things done. Don’t confuse this concept with the idea that “It’s better to ask for forgiveness than approval.” Knowing how to get things done is an important part of doing so. You do, after all, have to work on a team. Just don’t wait for an invitation.

This rule is about starting. Rule 7 is about finishing. They are two sides of the same expectation: move fast, and own the result.

Speed without accountability is just motion.

Rule 6 tells you not to wait for an invitation to act. Rule 7 tells you that when you act, the result is yours. These two rules are inseparable — one without the other is incomplete. Speed without ownership creates chaos. Ownership without speed creates bureaucracy. Together, they define what it means to be a high-performing team.

Owning an outcome doesn’t mean doing everything yourself. It means knowing what done looks like and doing whatever is necessary to get there. It means asking for help when you’re stuck rather than waiting for someone to notice. It means surfacing blockers early, escalating when needed, and closing the loop — every time.

In low-ownership cultures, problems drift. They travel from meeting to meeting, from team to team, accumulating handoffs and losing urgency along the way. Everyone assumes someone else is on it. In high-ownership cultures, that doesn’t happen — because someone has already decided the problem is theirs. That decision is often the only difference.

Ownership isn’t a title. It isn’t an assignment. It’s a decision you make when you see something that needs to be done. That might mean a customer issue your team didn’t cause. A process that’s broken upstream of you. A gap between teams that nobody owns. If you see it, you own it.

The customer doesn’t care who’s responsible. They care whether it gets done. Own the outcome, and that question never goes unanswered.

This rule scales. When individuals own outcomes, teams become self-directing. When teams own outcomes, organizations become self-correcting. The most resilient, high-performing organizations are built on cultures where accountability is not imposed from above but chosen from within.