The Books Every Startup CEO Should Read

Note: This post originally appeared on my Medium channel.

Since I’m always talking about the books I’ve read, I often get asked for book recommendations, especially by fellow Startup founders.

This morning Nick Rellas the CEO of Drizly asked me for a list of must-readbooks, so I quickly put together this list.

I think every Startup CEO & Founder would benefit from reading the books on this list.

Sorted by books I’ve re-read the most:

  • The Hard Thing About Hard Things — The only “real” business book. This book captures what it is like leading a startup.
  • Made in America — The story of how Sam Walton created Wal-Mart and became the richest man in the world. I have stolen many concepts from this book including the concept of Servant Leadership. Read 3x.
  • Seeking Wisdom — I can’t remember how I first found this book years ago, but it’s been on my nightstand ever since. I continuously read this book finding new gems each time.
  • Zingerman’s Guide to Giving Great Service — If you care about creating agreat customer experience read this book.
  • Managing Oneself — buy this tiny book by Peter Drucker and re-read it every five years.
  • Behind the Cloud — The story of Salesforce from its founder & CEO, Marc Benioff.
  • Let My People Go Surfing — The story of the founding of Patagonia and more importantly how to build a company with strong values.
  • Positioning: The Battle for Your Mind — This and Influence: The Psychology of Persuasion are the best books on Marketing. These books will teach you why you buy the things you do.
  • Meditations — So deep you need to re-read this book every few years.
  • Practicing The Power of Now — The best way I’ve found to deal with the daily anxiety of running a business is to focus on the “Now.” Start practicing with Tolle’s book.
  • Influence: The Psychology of Persuasion — I’m reading this book for the 3rd time now. The best book there is to understand the cognitive biases we all use to make decisions.
  • Entreleadership — If you want to learn how to work on your business, not in it, read this.
  • Setting the Table — I’m obsessed with great customer service. Nobody knows delivering great service better than Danny Meyer, one of America’s leading restauranteurs.
  • The Big Moo — So many great Seth Godin books to read, I’ve read all of them. I always come back to two books, Purple Cow and The Big Moo, a companion book to the Purple Cow.
  • Re-Imagine! — Too many great Tom Peters books, start with this one.
  • High Output Management — The book that started the recent OKR trend used by Google and many other companies to manage priorities.
  • Predictable Revenue — This book is a great guide to running a sales team from an early sales leader. I had a hard time choosing between this book and The Sales Acceleration Formula (read both).


Find out what I’m learning building my 5th startup, Drift, by subscribing to my free newsletter.


Read More

Finishing What We Started

I'm breaking my promise...

I made a promise this past weekend to the friends who had signed up for my newsletter that I was ditching my personal blog. My intention was to focus on my newsletter over my blog as a way to finally get back to writing. Well that promise did not last long.

 I want to publicly comment on some questions that have come up this week as the news of what we have been working on at Driftt has finally been made public. Just yesterday we had a great article published on BostInno and this morning I woke up to see that we had been hunted on Product Hunt.

For the last year at Drift we have been exploring how modern consumers and companies communicate. If you're interested in reading more about our exploration phase checkout the 3 phases of exploration post on our blog.

So where are we?

We're back to what we started back in the Fall of 2009.

We went "Back to the Future", back to where our obsession with building customer-driven companies, teams and software all started. Back to focusing every day on helping our customers delight their customers.

In 2009 we started Performable with a vision of bringing a unified customer view to Marketing teams in order to have them drive better experiences for their customers. 

In the summer of 2011 Performable was acquired by HubSpot. At HubSpot we narrowed our focus down to the first few steps in the customer lifecycle - attracting more leads (marketing) and converting them into customers (sales). Narrowing our focus was the right thing to do at the time and that focus turned out to be very successful for us at HubSpot. 🙏

After leaving HubSpot we spent a lot of time talking to companies everywhere trying to learn what had changed in the market. What we learned over the last year was that no company had successfully delivered at scale on the second half of the customer story we saw at Performable.

What happens after someone becomes a customer is even more important today than it was in 2009. I believe that Subscription Revenue Models are Eating the World across software, mobile, device (IoT) and offline businesses everywhere. 

With that massive shift happening and more companies depending on their customers to deliver a larger percentage of their revenue we decided to go back to finish what we had started in 2009 - helping companies better enagage with their customers.

At Driftt we believe that marketing to your customers and not strangers is the future of marketing. We call this Relationship Marketing and believe all businesses can do a better job at matching how modern customers want to experience their products and services. 

If you're interested in learning more I invite you to check us out at Drift.

P.S. This morning I found this old video (from early 2011) describing our vision at Performable. With your help we can finish this story at Driftt.

Read More

Creating A Customer-Driven Product Machine

Every company in the world will tell you they are customer-driven. They’ll believe in the principle. They’ll have framed posters on the wall about it. "Solve for The Customer." But none of that means anything unless you actually make the structural decisions to ensure it.

When I rebuilt the product team at HubSpot, back in 2011, I wanted to see if we could get beyond slogans and mantras to structure it in a way that intrinsically placed the customer ahead of everything else. I made a few decisions, in form, process and culture, that were designed to safeguard the team against misdirection and ensure that customers remained central.

(Note: This post first appeared on the Drift blog, where we share our thoughts on building customer-driven products, and teams.)

Units not Divisions

When you spend more time talking to “internal stakeholders” than your customers, you’ve lost the ship. That’s the truth. It’s a failure that can sneak up on you. One of the highest impact decisions we made at HubSpot was to constrain both the size of the teams working on a product and the scope of work they undertook. Small teams mean fewer distractions, less risk of getting mired in pet rocks, and a singular shared focus on the customer problem at hand. 

We started with a tight technical core of three people. No more. These small teams were hyper-focused and autonomous, owning both the product and the process for shipping it. Of the three developers, one takes the role of Tech Lead for the team. The Tech Lead drives timelines and project management, something other companies typically leave in the realm of the PM. 

That shift means that PMs, who work across dev teams, can focus solely on customers and vision. As Product VP Jeremy Crane explained in a recent post, “At HubSpot the product manager owns the ‘problem’ and the technical team owns the solution.”

Embedded resources
There’s an important distinction I want to call out here that small should not mean narrow when it comes to structuring product teams. While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. Similarly product marketers were embedded with the teams from day one working with product managers to understand the problem, develop the customer-focused positioning and execute a go-to-market strategy. The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed. 

Autonomy and Ownership
Ownership at HubSpot means that dev teams are responsible for the entire product including supporting the apps. There are no separate QA or release engineering teams. No fragmented view into whether or not their solution worked. Developers see products through. When a product succeeds, they own that. When a product falls short of solving a customer problem, they carry that weight too. And the iteration process begins. That’s why we shipped quickly and without a lot of executive interference. It’s about the relationship between the customer, his or her problem, and the product team trying to find a solution. We ship quickly, hear from the customer, regroup and ship again. It is this autonomy, fast learning and eventual mastery that drives us. 

There is no end-goal. The end-goal is evolution.
At HubSpot I made the decision to not set a public product roadmap. For a company that values transparency, it was a decision that led to a fair amount of hand-wringing from those wanting a reliable way of knowing what was coming next. The problem with product roadmaps however is that they often satiate company curiosity more than they solve customer problems.

I’ll give you an example. Let’s say as part of a public roadmap we commit to creating a certain app or feature. Once stated, the completion of that app becomes the end-goal. The sales team previews it. The business readies for it. But then in talking with customers and testing, let’s say we discover that the app doesn’t solve the problem at all. It’s a false approach. We’ve then got a dichotomy of needs on our hands. Do we serve the company who in stating it publicly has built up an appetite to see this app in the wild? Or do we serve the customer, abandon the approach and build the thing that’s actually going to work? 

Roadmaps solve for the company not the customer. What solves for the customer is non-stop testing and a continuous improvement. Instead of having 2-3 releases a month, we had 1000s. Instead of building up a release for months, we got it into the hands of beta users immediately, often before a HubSpot executive had seen it, so that the customer could help us correct and iterate on our direction. 

The framed poster on the wall would tell you customer happiness is everyone’s responsibility. Maybe, but that's a really unproductive way to achieve it. As the old axiom says, if everyone is responsible, no one is responsible. By keeping teams small and autonomous, and giving them concrete ownership of specific problems rather than abstract ideas, we were able to build a product team that truly solved for the customer.

Read More

Like this post? Subscribe by email or say hello on Twitter: @dcancel.