Bill Campbell is one of Silicon Valley’s most influential figures, yet most people outside the industry have never heard of him. Known as “The Coach,” he mentored Steve Jobs, Eric Schmidt, Larry Page, and countless other tech leaders. He served as Intuit’s second CEO and chairman of the board for over a decade. He preferred to work behind the scenes, take no credit, and let the people he coached shine.

In a rare fireside chat at Intuit, Campbell shared his philosophy on what it takes to build great products and lead great teams. What follows are the key lessons from that conversation.

A Coach, Not a Teacher

Campbell draws a sharp distinction between coaching, teaching, and leading. A teacher presumes they know the curriculum and imparts wisdom. A coach seeks to understand where the leader wants to go and helps them get there — through course-correcting on priorities, managing crises, and working through interpersonal conflicts on management teams. His work was always one-on-one with CEOs, not one-to-many.

On the difference between management and leadership, he is equally clear: “Your title and what you do makes you a manager. A leader is something people bestow on you. You have to earn that from your people.” He wanted every person he coached to be a good manager first. Leadership, in his view, was something that followed from earning the trust of the people around you.

Coachability Is the Price of Admission

Campbell was generous with his time, but not indiscriminate. He would only coach people he considered coachable. His very first question to Jonathan Rosenberg, who went on to lead products at Google, was blunt: “Are you coachable?”

What he meant was: are you humble enough to learn? Are you willing to hear hard truths and act on them? Failure was acceptable, even valued, but only if you learned from it. Arrogance was a dealbreaker. If someone was not open to feedback, Campbell simply would not invest time in them. Grit — how people responded to stress and setbacks — was the signal he watched for most closely.

Let Go of the Reins

Early in his career, Campbell learned a lesson about delegation the hard way. At Claris, his first startup, Donna Dubinsky confronted him directly: “If you’re going to make all the decisions, all of us are going to go back to Apple. You hired us because we know what we’re doing. Let us run our groups.”

It stuck with him. From that point on, his approach was to hire people he trusted and then get out of their way. His job was to course-correct, not to dictate. This philosophy runs through everything else he teaches — empowering engineers, letting product managers edit rather than direct, and creating environments where talented people can do their best work without being micromanaged.

Great Products Come From Great Engineers

Campbell’s central thesis is that product excellence starts with engineering. Not engineers who take orders, but engineers who deeply understand problems and devise creative solutions. He draws a sharp line between what he calls “code jockeys” and true product engineers. The former write code to spec. The latter understand the customer, the business, and the technology well enough to propose solutions no one else would think of.

He tells a story from his early days in tech about banning business hires from dictating features to engineers: “If you ever tell an engineer what feature to put in, I’m gonna throw you out the window.” The point is not that business context does not matter. It is that the best products emerge when engineers are empowered to solve problems, not just implement requirements. He points to founders like Zuckerberg, Drew Houston, and Jack Dorsey as examples of technical people who understand how to apply technology to real problems.

Product Managers Are Editors, Not Directors

Campbell borrows a framing from Jack Dorsey: product managers should think of themselves as editors. They refine, guide, and course-correct, but the creative engine is engineering. He cites the example of Phil Schiller and Scott Forstall convincing Steve Jobs that the iPad needed practical features like reading Excel files. That is product management adding value without overriding engineering vision.

His advice to product managers is direct. Spend 80% of your time working alongside engineers. Understand what they are building and why. Stop writing checklists and tracking dates. Your job is to make the product better, not to manage the process of building it.

Leaders Create the Environment

You do not have to be an engineer to drive product excellence. Campbell credits Brad Smith and Steve Jobs as non-engineers who created environments where engineers thrived. They did it by removing barriers, caring deeply about products, and spending significant personal time reviewing the work.

He recounts Eric Schmidt’s envy of Zuckerberg sitting with engineers at 5pm, casually discussing features. The lesson is that great leaders carve out time for product. They do not delegate it entirely and show up only for quarterly reviews.

Creating the environment also means making it safe to take risks and speak up. Campbell was not afraid to take people to the woodshed when they needed hard feedback. But he always followed up with warmth and re-acceptance. The lesson: you can show anger, you can deliver tough truths, but you must bring people back with you afterward. If people feel they will be judged unfairly, they stop taking risks. Psychological safety was not a buzzword for Campbell. It was a prerequisite for the kind of environment where great work happens.

Manage Three Horizons

Campbell describes three product horizons that every company must manage simultaneously:

  1. Evolve what you have. Make existing products faster, tighter, and more reliable. This is the bread and butter.
  2. Reimagine the problem. Solve the same customer need in a fundamentally new way. Mint reimagining what Quicken did is his example.
  3. Invent from scratch. Create something entirely new, like SnapTax emerging from unstructured exploration time.

The trap is overvaluing the new. If all your best engineers chase the next big thing while existing products stagnate, you lose the customers who pay the bills. He points to Gmail staying in beta for years because core engineering attention drifted to new projects as a cautionary example.

Break Ties and Kill Politics

When asked about managing internal conflict, Campbell calls it “probably the best question I’ll get in a year.” He is emphatic that internal politics will bring companies to their knees.

His approach is straightforward. When two teams or leaders are deadlocked, set a deadline: “I want you guys to solve this by Friday. If you don’t solve it by Friday, then I’m gonna solve it.” Most of the time, people find a way to work it out when they know the alternative is losing control of the decision. And when they do not, the leader must act decisively. He contrasts the chaotic Apple under John Sculley, where people just went and did whatever they wanted, with effective leadership that demands collaboration and is willing to fire somebody for not cooperating.

Open vs. Closed Is Not a Religion

Campbell gives a nuanced take on the open versus closed platform debate. He praises Apple’s walled garden for controlling customer experience and app quality, while noting that Android’s openness enabled competitors like Amazon to use it against Google with the Kindle.

His conclusion: truly ubiquitous technologies, like web standards, should be open. But product platforms require careful judgment. Apple found a middle ground with open APIs for developers but a controlled OS and curation process. The answer is not ideological. It depends on what you are building and who you are building it for.

Vision and Experimentation Are Not Opposites

Responding to a question about the Steve Jobs “auteur model” versus lean experimentation, Campbell argues they are not that different. In earlier eras, you had to make big bets because iteration cycles were 12 to 18 months. Today’s environment enables rapid feedback and course-correction.

He endorses a simple framework: most decisions are fact-based and testable, so run experiments. For the rare opinion-based decisions where data cannot settle the question, have the courage to make the call, but also the courage to reverse it if you are wrong. He uses Ron Johnson at JCPenney as a cautionary tale of someone who put a bullet hole in his current business before the new vision was proven.

Design Is a Principle, Not a Department

Campbell pushes back on treating design as something layered on at the end. Engineers should get products 90% of the way there on usability, with design providing course correction and finishing touches. He cites Amazon’s one-click ordering as a “design principle” that was fundamentally a functional engineering breakthrough, not a cosmetic one.

Design principles should unify the product experience, but engineers must internalize them. If you need a separate design team to make your product usable, your engineers are not thinking about the problem broadly enough.

People and Products

In his closing, Campbell distills everything to its essence: “You care deeply about people, you care deeply about products. What else is there?”

When Eric Schmidt, Jonathan Rosenberg, and Alan Eagle interviewed over 80 people for their book Trillion Dollar Coach, one word came up in nearly every conversation: love. How much they loved Bill, how much Bill loved them. He treated people as whole human beings — professional, personal, family, all of it — not just as workers filling a role. He had a habit of taking five minutes after a big milestone to recognize the junior person who actually did the work. It cost him almost nothing and meant everything to the people on the receiving end.

That is the whole philosophy. Build environments where talented people can do their best work. Focus relentlessly on the product. Care about the people around you as human beings, not just as contributors. Everything else, the strategy, the process, the org chart, exists in service of those things. It is a simple idea, and like most simple ideas, it is extraordinarily hard to execute. But if you get it right, Campbell argues, everything else follows.