It Was Never About Revenue · The Revenue-Oriented Product Team

This course is not about being revenue-oriented. It is about being customer-oriented, because when you are customer-oriented, the revenue tends to take care of itself. I said in Chapter 1 that the final chapter would reframe everything before it, and that I would hold that card until then. Consider it played. Eleven chapters of machinery, and every piece of it is a way of getting the truth about customers in front of the people who can act on it, at the moment they can act.

The qualifier belongs next to the claim. In the immediate term, there are ways to drive revenue faster than customer orientation: squeeze the pricing, discount into the quarter, gate a feature the install base already depends on. In the long term, there are not. That is an opinion. I have held it through ten years inside one company that crossed over and several more building another on the premise, and nothing in that time has come close to changing it.

SOMETHING SIMPLE ABOUT PEOPLE

Trillion-dollar companies are tied to the human experience and to the actual value of the product. The iPod is the cleanest example we have. Steve Jobs promised a thousand songs in your pocket, and the promise came from understanding something very simple about people: they loved their music and they could not carry it with them. The revenue curve after revenue curve, the S-curves, the business school case studies, the trillion-dollar valuations all came later, and none of them arrive without that one piece of understanding sitting at the center of a product decision.

Your company is not Apple, and neither is mine. The scale changes; the mechanism does not. Whatever your product is, somewhere in it there is a simple truth about the people who use it, and the degree to which your team organizes itself around that truth is the degree to which the revenue math of the last eleven chapters works.

THE COURSE, READ BACK

Go back through what you built and read it with the customer at the center.

The two-sip answer is customer mastery. The co-op's answer connects to what the CEO said at company meeting because a customer's situation runs through both ends of it. The common language is customer evidence: revenue by feature and renewal risk by bug take what customers said and attach it to the work, and the join that ended the rival summer camps is a shared view of the same human beings. The renewal clock is customer stakes: the date in the contract is the day a person who bet their job on your product decides whether the bet paid. The CEO brief is customer truth: what shipped, for whom, connected to the promises the company is out making.

And the question this course opened with, what could we do with these laptops to fix this in production, permanently, was a customer question the whole time.

THE CHARGE

Do the exercises. They are easy to do and hard to look at, and if you read every chapter and did none of them, you have some notes and an opinion. None of the work requires budget, permission, or a reorg; attitudes and information, in that order, and both are available to you today.

Then go be loud about it. The end state I want for you is specific: you walk out of this, grab your friends in product, engineering, and design, and tell them there is a whole different way to be doing all of this. One that is more fun. One that makes the team look better. One that makes the CEO happier. All three are true, and after the sprint below, the evidence is on your own laptop.

THE EXERCISE

The capstone is a thirty-day sprint.

The six pieces come from earlier chapters:

Your one-page species assessment (Chapter 1).
Your page from the mock sales call: what it felt like, which objections landed, and what reps absorb (Chapter 6).
The feedback-path map, annotated where information gets lost (Chapter 7).
Your monthly update, warts shown (Chapter 8).
The renewal table for your top ten accounts (Chapter 10).
One story for your engineers: logos, dollars, renewal dates, and the customer's own words (Chapter 10).

Run the prompt with all six, then work its plan: publish the update, pin the renewal dates where you'll see them, send a CSM the first note, and tell your tech lead the story. On day thirty, fill in what changed and send its note to your friends in product, engineering, and design.

THE PROMPT

Paste this into whatever AI you work in, ideally one connected to your company's material: Claude Code in a company-brain folder, Cowork, Codex, or similar. Bring all six artifacts, rough ones included.

I'm in product, starting a thirty-day sprint to put what our customers need in front of the people who can act on it. My six artifacts are below or in this folder:

-whether we're sales-driven or product-driven, with evidence

-a page from a mock sales call: what it felt like, which objections landed, and what our reps absorb

-how sales feedback reaches our backlog, and where it gets lost

-a monthly update to sales, CS, and leadership, warts shown

-renewal dates for our ten most important accounts

-one story for engineers: who asked, their contract values and renewal dates, their own words

1.Check each against the material you can reach (calls, the CRM, contracts, the issue tracker, Slack). Mark it ready, weak, or missing, and cite what it got wrong or left out. If I say one is in use, ask who used it last and for what.

2.Where the record is thin, interview me, one question at a time.

3.Plan the thirty days by week, starting with the gap that most helps the rest: what I fix, publish, send, and tell, and to whom. Mark the steps that could later run on a schedule.

Hand back the audit, the plan, and a note in my voice to my friends in product, engineering, and design that starts "There's a whole different way for us to be doing all of this," with a blank for what changed.

OR RUN IT AS A SKILL

WHO THIS HITS HARDEST

Everyone, on the second pass. Reread this chapter after the thirty days, when the first sentence has stopped being a claim and started being a description of how your team works.