One day while I was running Product at HubSpot, we hosted Henry Ellenbogen, a legendary investor that most people have never heard of. Henry ran the New Horizons Fund at T. Rowe Price through an outlier stretch and today he runs Durable Capital Partners. Henry's firm is well-named; he focuses on the underlying quality of a management team and the durable aspects of a company that create value over the long term. He came to talk with our leadership team about an idea he'd formed across decades of looking at every technology company that mattered.
Henry told us there are two species of companies: sales-driven and product-driven. In his years of investing, he had only seen one sales-driven company transform into a product-driven one. The exception was, of course, the company in that room.
By then we were a twenty-five to thirty billion dollar enterprise and growing. I had watched the whole transformation from inside, and a lot of it from the cockpit. This course is what I learned: how the crossing was done, why it almost never happens, and how to work toward it from any seat in a product organization, starting this week.
TWO SPECIES
But first, we need to understand the difference between product-driven and sales-driven companies and why it matters.
Which species a company belongs to traces back to the founder almost every time. A go-to-market founder builds a company that reflects them: scoreboard-driven, results-oriented, aggressive, willing to solve any problem however necessary. That mentality produces good numbers on the scoreboard, and if the company sells software, it eventually has to figure out product, with all the difficulty that implies.
Product-driven companies are the rarer species, even among the wildly successful ones. Their advantages run deep and they demand more patience. The core of it is compounding. Any problem in a business that you solve with product keeps paying: the fix works tomorrow, next quarter, and for every future customer, with no one's continued effort. Any problem you solve with people and analysis adds overhead and complexity, and in many cases the returns compound in the wrong direction. The org chart grows, the process count grows, and the energy that should have gone into the product goes into coordinating the workaround.
Follow that logic up to the executive team and you can see the species in how people spend their time. In a product company, the executives are looking at the product, talking about the product, making product bets. Finance is in the product conversation productively. Legal is in the product conversation productively. I was fortunate to experience that, and I can tell you it is unfair. Picture a leadership team in a room working out a plan where the product will hold COGS in line, lower the hiring forecast because fewer people are needed, improve support, improve NPS, and drive the top of the funnel, all at once, all permanently. You do not want to compete with that company.
WHAT CROSSING OVER LOOKED LIKE
I came to HubSpot in an acquisition. The mission my team was handed was to back up the go-to-market momentum with a product platform that would do it justice, close the customers the machine was attracting, and retain them.
The go-to-market really was that far ahead. Our founders invented inbound marketing, the idea that you offer something of genuine value as a magnet for your business. It was so correct that it no longer needs a name; like "color TV," it's just marketing now. In those days, a buyer would come in, have one or several calls with sales, and reach a purchase decision without knowing they were talking to a software company. For about half my ten years there, the conversation about the revenue number, lead volume, lead quality, territories, and demand belonged entirely to marketing and sales. That was one political party of the company. Product and engineering were the other, and our platform was, in effect: leave us alone. Get us great bike parking and very good cold brew, get the light right, get us monitors, and above all give us a great peer group and time, and we'll build you a great product.
And we did. That stretch was an amazing product run. But by the time I left, most people who ever spent a dollar with the company had spent serious time in the product first, most of them before they ever spoke to a human, and the product team carried close to two-thirds of the demand SLA.
If you've spent your career in product, that sentence may need translation. An SLA, a service level agreement, is one team's quantified promise to another inside the company's financial plan: we will deliver this many qualified signups, this much pipeline, by this date, and we will be measured on it. Many product teams have never carried any SLA and have only heard the term in the uptime clause of an enterprise contract. Once you become revenue-driven, promises between groups become core language, because a promise between groups is quantifiable and someone can be accountable for it.
That is the destination. A product culture where seeing a bug, a churn pothole, or something amiss produces, as the first thought: what could we do with these laptops to fix this in production, permanently?
WHY ALMOST NOBODY CROSSES
The first reason is the simplest: it does not occur to them. Most sales-driven companies never try. The industry has fashions, and some years product culture is in vogue the way hypergrowth was in vogue the year before and taste and refinement will be the year after. Companies that actually cross ignore the fashion cycle entirely; they just do the work every day while the memes come and go.
The second reason is that the required behavior change, especially in engineering, is enormous, and you cannot memo it into existence.
At one company, years into this work, we were doing a period with an enterprise team and hit a gnarly authentication issue with a great account: big impact, excited customer, a whole new slice of the market. Our instinct was the obvious one: connect our best engineer directly with the customer's technical contact and take care of them. Where I come from, an engineer jumps at that. This engineer made it through one ticket and informed his supervisor that if he was ever brought into a similar conversation again, he would leave the team. I went back through the history to see how bad the exchange had been. It was fine. Nothing rude, nothing unreasonable. The culture he'd grown up in simply held that talking to customers was not his job, and one ticket of it was a resignation-grade offense.
At Day AI, an engineer hopping onto Slack with a customer is as normal as pouring a glass of water. Ask one of our engineers how it feels to fix a customer's problem in production while the thread is still warm and they'll tell you it's the most fun part of the job.
Same role, same talent level, opposite reflexes. The distance between those two scenes is the actual work of becoming product-driven, and most leadership teams have no idea the distance exists, because nobody writes "will refuse to speak with customers" on a resume or in a culture deck.
Here is what the distance is made of. You know the feeling, as a user, of paying for a product that has dumb stuff in it, edges you bump into every week, and sensing from the outside that nobody there cares. You don't know anyone at the company; you just know. It changes your relationship with the product instantly. When the product people actually care, you can also feel it. Details improve that no chief product officer would think to put on a roadmap, and sharp edges get smoothed, because individual people give a damn about individual customers. That hits the bottom line.
WHAT "REVENUE-ORIENTED" WILL MEAN HERE
The rest of this course walks the same route the transformation actually takes. First the mindset: what product management owes engineering, and why the single biggest advantage you have in your career is your attitude. Then the CEO, because whoever you are in the product org, you work for them, and most product people cannot say what keeps their CEO up at night. Then the departments across the wall, sales and customer success, where the richest information in your company is sitting largely unread by the people who could act on it. Then the view from the CEO's own chair. The final chapter reframes everything before it, and I'll hold that card until then.
Two things run through every chapter. The first is that this is a course about attitudes and information, in that order. Almost nothing in it requires budget, permission, or a reorg. The second is that the information half has collapsed in difficulty. The primary source material of your business, the calls, the threads, the tickets, the usage, was always the goldmine, and in 2026 the tooling to read it, on a loop, in five minutes, exists on your laptop. Every chapter ends with an exercise and a prompt you can paste into Claude Code and run against your own company's material. The exercises are easy to do and hard to look at, and if you skip them you'll finish with some notes and nothing else.
MAKING IT REAL WITH INTERACTIVE EXERCISES
The exercises in this course are meant to help you apply the concepts from each chapter to your own reality. As a PM today, you are already using AI tools to get your work done more efficiently. At the end of each chapter we've provided prompts that will push you to think about how the concepts apply in your own company. Many will draw on your company context, so they'll work best if you have a place with that context already connected: maybe a folder where you use Cowork or your Claude account with MCPs connected.
EXERCISE 1: WHAT TYPE OF COMPANY ARE YOU?
Before we dive in, you should have a clear point of view on where your company falls on the spectrum of sales-driven and product-driven.
First, try to answer this yourself. Write down two columns on paper, one for product-driven, one for sales-driven. In each column write down behaviors that suggest your company is either product-driven or sales-driven.
Apply the auth-engineer test to your own team: if a customer issue needed an engineer on a thread with the customer today, what would actually happen?
Now, let's pressure test this against your real company. Paste this into wherever you normally work with AI for product.
OR RUN IT AS A SKILL
WHO THIS HITS HARDEST
Everyone; this is the course's thesis chapter. If you're an APM, the species question explains most of what confuses you about your company. If you're a CPO, you already know your answer and the exercise will tell you whether your team knows it too.