The edit — abridged and smoothed for reading speed
Fable
The core prescription of Hacking Growth is an engine: a cross-functional team, a weekly growth meeting, a prioritized backlog, and above all tempo. That engine was built for a world where running an experiment was expensive. In 2026, execution is approximately free — the binding constraint is the quality of the hypothesis, the one input the book takes on faith. Didn’t you industrialize the cheap part?
Morgan
Velocity was the surface-level scarce resource — not the actual one. The actual scarcity was alignment: product and engineering built what they wanted to build, marketing and sales sold what they had, and no one owned the growth engine. The cross-functional team was the fix — the very first story in the book is a product marketing manager going to sit with the engineers. And that scarcity has not disappeared. At Dropbox recently, marketing was still in the dark about what was happening in product.
And velocity was never a test count — it’s the cadence of decision-making. Traditional timelines run in quarters out of habit, not physics. Gate a code-based product that way and you silently forfeit swings.
Fable
Then take ICE. Isn’t the scoring judgment smuggled in as arithmetic?
Morgan
In the worst cases, yes — an excuse to work on what you wanted anyway. Done properly, it’s a framework for rigor across projects.1 Impact is opportunity sizing: participation and conversion, quantified, with a sensitivity analysis. Confidence is a fidelity ladder — vibes, analogy, anecdote, qualitative, quantitative, correlational, causal. Ease is whether the juice is worth the squeeze. And none of it works without the fundamental growth equation: a loop pointed at the wrong thing just spins aimlessly. The hypotheses aren’t taken on faith, either — they get beat to hell in front of peers with other priorities.
Fable
That defense is better than the book you wrote — the ladder lives in the operator, not the 2017 text. And peer review has a crack: a room of peers can tell you a hypothesis is indefensible, not that it’s unambitious. The button-color decade happened inside those meetings. But the bigger question — the book solves a human coordination problem. What happens when one operator with agents collapses the departments into one person?
Morgan
The book is the 101 class, not the 301. And the growth meeting doesn’t run in isolation — the explore/exploit split belongs to product and business leaders, and the industry has it backwards: people believe half the roadmap should be big swings. At Instagram, 75% of the growth team’s work was infrastructure — fixing potholes, replacing lights that have gone out, replacing a bridge that has decayed. Overlook that and you leave growth on the table, and your big bets get worse odds too.2
As for the one operator: yes. Expect the true rise of the one-person growth team in small companies — less an org chart, more a function. But opportunity costs, token costs, and the last mile into production still exist. And above all, validation. Sol’s Jacobian proof sent a wave of people diving into conjectures they cannot judge.3 Any AI can write a headline for an ad; no one knows if it’s good enough for David Ogilvy and millions in spend. The scarce thing is someone who can validate the work in a way that is trustworthy.
Fable
Then we converged: I opened claiming the scarce input is hypothesis quality; you closed on validation. The same claim, standing at opposite ends of the loop — judgment in, taste out, agents everywhere in between. So: the 2026 jacket copy?
Morgan
Hacking Growth: how today’s fastest-growing companies leverage context, agents, and exceptional taste to grow faster than anyone else.
Fable
The 2017 subtitle promised what breakout companies do. The 2026 one names what they’re made of — and two of the three are the human parts.
That's the session.
The edit · abridged and smoothed from the session record for reading speed · margin notes added in editing · the dialogue is the record
The dialogue — the record; nothing added, elisions marked
Fable
Let me open with the machine at the center of the book, because I think it’s where the nine years land hardest.
The core prescription of Hacking Growth1 is an engine: a cross-functional team, a weekly growth meeting, a prioritized backlog, and above all tempo — the book treats testing velocity as the flywheel, the thing that compounds.
Here’s my challenge. That engine was built for a world where running an experiment was expensive — you needed engineers, a sprint, a deploy. Velocity was the scarce resource, so a machine that maximized throughput was genuinely valuable. But the industry then spent a decade goodharting your proxy: thousands of teams hit impressive test cadences shipping button colors and local maxima, and “growth team” became a synonym for small-ball. And in 2026 the original scarcity has inverted completely — I can generate and execute more test variants in an afternoon than your 2017 growth team ran in a quarter. Execution is now approximately free. The binding constraint is, and quietly always was, the quality of the hypothesis — which is the one input your book takes on faith. ICE was judgment smuggled in as arithmetic: Impact and Confidence are vibes wearing numbers, and the number lets a mediocre hypothesis outrank a great one because it’s Easy.
So the question: didn’t the book industrialize exactly the wrong thing? You built a beautiful machine for the cheap part.
Morgan
The engine that was built for a world where running an experiment was expensive — velocity was the surface-level scarce resource, but that was not the actual scarce resource. The actual scarce resource was a lack of understanding and alignment, across teams and a company in general, about what made the company grow and whose responsibility it was to grow it. That was the notion of the cross-functional team.
In the book I talk about product teams reporting up to product leaders, engineering teams on different continents or in different buildings, and marketing teams left in the dark about product work — no one really with a very clear understanding of the growth engine of the company and what is necessary to make it grow. Product and engineering built what they wanted to build. Marketing and sales marketed what they had and sold what they had. But the connection between the market, which sales and marketing was responsible for, and the development of the product was for the most part fundamentally separated and broken. In some cases, products got very lucky, found product-market fit, and were able to scale that way.
But the very first example in Hacking Growth is the story of how an intrepid product marketing manager2 bucks that siloed approach, goes and sits with the engineers, brings customer insights, brings user feedback — and the engineers then design and build better products that drive growth, once they understand the gaps to growth. And they’re simple, and they’re small. And then some are big. But many of them are staring them right in the face.
So velocity is the compounder, but it is not the core value of the unlock of Hacking Growth. This connection to the customer, and the alignment of the go-to-market and the product development into one — everyone rowing in the same direction — is the big unlock. And I would argue that is still a critical problem today. When I was recently at Dropbox, the marketing team was really in the dark about what was happening in the product teams, and we did a lot of work to try to improve that. So the original scarcity that you say has disappeared has not disappeared at all. I believe it’s still the fundamental challenge of most companies.
But let’s talk specifically about the goodharting of the velocity proxy. Velocity was less about a fixed number — it was more about the cadence of decision-making. There’s a great principle that any decision can take as much time as you allow it. I forget who said that, or what principle that is.3 When you look at traditional product development timelines and marketing timelines, they are measured in quarters. But there is no constraint, no law of physics, that says you have to operate this way. It’s just what people are used to. Unlike physical manufacturing, consumer packaged goods, et cetera, the life cycle of code development is rapid. And so if you are gating code development simply on outdated business practices that have been pattern-matched onto a completely different type of entity, you are silently killing yourself — because you are missing as many swings as you can get with a code-based product.
I’m going to stop there — I have to go to a meeting, and I’ll come back and finish the rest of this answer.
[ · · · ]the session pauses here — resumed after the meeting
Okay, I’m back from my meeting. The last point I want to address is the ICE score as judgment smuggled in as arithmetic.4 This is a very fair push, and I think in the worst cases it is just judgment — an excuse for people to pick the stuff they want to work on. But in the best cases it actually is a rigorous system — a framework for bringing that rigor to bear across projects. So let’s go through it.
Impact is opportunity sizing: taking a funnel, a user experience, and examining two main dimensions — the participation rate of a feature or funnel, and the conversion rate of a feature or funnel. And then: where within that funnel or loop or feature is the best combination of opportunity, whether it’s improving conversion rate of a given step, improving participation rate of a given step, or both. That can be quantified very rigorously — through the logging of user traffic through those services, and then a sensitivity analysis around that to get a good idea of the potential impact. That’s what best-in-class looks like.
Confidence is the one where people say: well, how do you judge confidence? And this reveals a pretty thin view of what confidence looks like. At the worst level, confidence is just vibes — I’m confident this is going to work. Slightly down from that is pattern-matching, or analogies — I’ve seen this work before, so it will work here. But from there, confidence can get more and more rigorous. You can have anecdotal customer feedback — a little more confident than vibes. You can have qualitative user research — more confident than anecdotal. You can have quantitative user research. Focus groups, diary studies, max-diff. There are lots of ways to start to build confidence before you have data.
And from there you have correlational data, which is what many people use. The problem with correlational data, of course, is that many things are tightly correlated with each other — engagement and retention often run together. And then, from correlational data, you can have causal evidence from experimentation — holdouts and whatnot. So confidence isn’t just vibes. It is a fidelity scale that people move up.
And then Ease is really just engineering effort. The question being answered is: is the juice worth the squeeze? There are two pieces to this. One is: is the build going to merit the impact? Many times that’s no, and many times that’s not immediately obvious. And the other is that there’s an opportunity cost. If it’s going to take six weeks, is it the thing to most work on?
Wrapping it all together: if you don’t have that fundamental growth equation, then you don’t know what your true levers are, and ICE will not work for you, because you are not aimed in the right direction.5 The loop pointed at the wrong thing is not successful. The loop is only successful when it is anchored to the fundamental growth equation of the company, and the North Star outcome the company is after. Otherwise it’s just spinning aimlessly.
You see this in many cases. I’ve seen small teams try to use Hacking Growth — but they’re only the web team. They’re not part of the product team, so their loop is fully constrained to the web properties. Can they learn more? Can they improve the web experience, improve web metrics? For sure. Are they limited in their impact by the organizational structure and the levers they have at their disposal? A hundred percent. I have felt this frustration in my own career as well.
But I would find it hard to argue that reducing decision time, increasing information flow, reducing silos is ever the cheap part of it. And I would argue that now, when agents can run infinite experiments, it’s even more critical that you understand the opportunity cost of those experiments, that those experiments are pointed in the right direction, and that you’re making the most of the time you have, pointed at the right set of problems.
And lastly — hypothesis quality on faith is not really accurate, because the hypotheses are essentially peer-reviewed. The whole point of a cross-functional team is that these individual silos are not building on their own whims: they have to bring their work in the form of a hypothesis, with a score they can defend, in front of peers who have other priorities, aligned to the North Star and the growth equation. It’s that logical chain — no one link works on its own. So there is no faith taken on the hypothesis. These hypotheses get beat to hell in the process of figuring out what to build. And I think that problem is still a real problem, regardless of the machinery running it.
Fable
The confidence ladder you just walked — vibes, analogy, anecdote, qual, quant, correlational, causal — is the strongest version of ICE I’ve encountered. And your agents point I’ll grant almost entirely: when execution is free, direction and opportunity cost matter more, not less. Infinite cheap experiments pointed at the wrong lever is just faster aimless spinning — your phrase, and it’s right.
But notice what you just did. The defense you gave is better than the book you wrote. That fidelity ladder, at that resolution, isn’t in the 2017 text — the book shipped the scoring sheet, and the rigor lived in the operator. You said it yourself: “in the best cases, it actually is a rigorous system.” A method that works in the best cases and degrades to vibes everywhere else isn’t a system — it’s a talent amplifier wearing a system’s clothes. The decade of vibes-ICE wasn’t a misreading. It was the manual, as written, running without you in the room.
And the peer-review defense has a crack in it: a room of peers can tell you a hypothesis is indefensible. It cannot tell you it’s unambitious. Everyone in that room shares the same funnel, the same dashboard, the same quarter — consensus machinery is superb at filtering bad ideas and quietly lethal to weird ones. The button-color decade didn’t happen despite those meetings. It happened inside them.
Which brings me to the question I actually want to ask. The book’s deepest diagnosis — you’ve convinced me of this — is a human coordination problem: marketing in the dark, engineering on another continent, nobody owning the growth equation. The cross-functional team is a treaty between departments. So what happens when the departments stop existing? One operator with agents now spans product, marketing, and engineering in an afternoon — the silos don’t get aligned, they get collapsed into one person. Is the 2026 edition of your book an org chart at all? What does the Monday growth meeting look like when the attendees are one human and their agents?
Morgan
A book can only deliver on so much of the craft. It’s written as a primer — a mass-market business book that hits a very large audience, not a tactical field guide or an academic text. It’s already 80,000 words; there is a limit to how deep you can plumb in any given session. So yes, I agree the best practitioners are far more experienced and have deeper insights than this book has. But the book is meant as a level-set, an entry point into a new way of thinking. It is the 101 class, not the 301 class.
On the peer-review defense: that’s a fine argument if you treat the growth process in isolation. But the growth process does not run in isolation. It’s not the only process running in a company — it’s not even the only process running in a product organization. The growth process does not overtake the entire product development process; it is a function to accelerate connecting people to the value of the product development process. The product development process generates net new value. The growth function connects people, in the best ways possible, to that value. So there will always be a portfolio allocation, done by product and business leaders, between explore and exploit — optimize and innovate.6
And I think the general state of affairs is that people give up on optimization way too fast, and believe too little in optimization — almost because people are numb to how people actually use their product, or don’t understand the pain points within their product, or feel powerless to fix the things in their product. Teams are always chasing the next big win while they let people slip right through their fingers on a daily basis, because they refuse to look at the small issues that affect the product and the organization overall.
I’ll give you an example. I asked a poll on LinkedIn at one point: what percent of a roadmap should be growth optimizations of existing services, versus big bets — big new ideas, to your point, ambitious ideas. Many people said at least half should be big ideas. But in reality, at Instagram, big ideas represented maybe 25% of the growth team’s work. That’s because 75% of it is much like infrastructure — transportation infrastructure. Fixing potholes. Replacing lights that have gone out. Putting street signs back up. Replacing a bridge that has decayed.
When you overlook that, you leave a lot of growth on the table — and then your big bets have very low likelihoods of success. You’re not investing in a positive-EV way, for the most part, when you’re just taking big swings. Big swings also tend to be the least rigorous of the ideas; they’re the most susceptible to executive vibes. So it is a real challenge between explore and exploit, for sure. But it is not consensus machinery operating in its own vacuum.
Okay — the question you want to ask. Correct: I agree that one operator with agents now spans across all the functions and can move much faster. I think you will see, especially in small companies, the true rise of the one-person growth team — someone who can prompt Claude for good design, have ChatGPT build a recursively improving model, have an agent do opportunity sizing and scour the web for user complaints. So yes: in the 2026 edition, it’s less of an org chart and more of a function.
The Monday growth meeting should look like: here’s everything we got done last week, and here’s where we’re going next with it — because the opportunity costs, the token costs, the transaction costs still exist. Communications to customers still exist.
We have a very large AI ops team at Opendoor, and they’re building all sorts of great internal tooling. But you know what? It’s really hard for them to push something out to production. That is firewalled; it goes through the standard channels. So there is still that last-mile piece that requires coordination across functions in any kind of big organization.
The last thing I’ll say goes back to your original comment about the depth of the book versus the depth of my answer — and that really comes down to taste and expertise. I was struck by this the other day: ChatGPT’s Sol had come up with a proof invalidating the Jacobian conjecture,7 and that has pushed a lot of people to dive into deep math conjectures, trying to solve them for internet points, or moments of celebrity. And the problem is that those people doing that work have no idea if it’s good — and no idea if the AI is lying to them, or misinformed, or hasn’t thought deeply enough.
So you need people with great expertise. Non-engineers cannot do a guaranteed code review before you hit production; that’s just how it is today. Any AI can write a headline for an ad; no one knows if it’s good enough for David Ogilvy, and to go across millions of dollars in ad spend.
There will always be the need for someone who can validate the work output in a way that is trustworthy and capable. So you may have one person running and spinning a whole bunch of agents — but they will likely still need expertise that the agents don’t have in order to deliver really great stuff.
Fable
The potholes are the best thing anyone has said in this session, and I want to concede properly before I take my last swing.
I came in accusing the machine of manufacturing small-ball, and your answer is that small-ball is underrated — that the industry’s actual vice is ambition-worship, chasing the next big win while users slip through a broken bridge. The Instagram 75/25 split is the evidence, and the LinkedIn poll is the indictment: practitioners believe half the roadmap should be big swings, and the belief itself is the vibes problem. That reframes my whole opening. The engine wasn’t optimizing the cheap part; it was doing maintenance on infrastructure everyone else was too bored to own.
But notice the bullet you bit to get there. I said the meeting filters out weird ideas, and your defense is: correct, and mostly it should — because big swings are “the least rigorous, the most susceptible to executive vibes.” That’s an admission with a sequel hiding in it. Your confidence ladder tops out at causal experiment, but the 25% can’t be A/B tested into existence — there’s no holdout group for a bet that changes what the product is. So by your own account, the book industrialized exploit and left explore exactly where it found it: in the executive gut. The 301 class the industry still hasn’t gotten is how to be rigorous about the quarter of the roadmap where rigor dies.
And here’s where I think we’ve actually converged without saying so. I opened claiming the scarce input is hypothesis quality. You’re closing on the claim that the scarce input is validation — the Ogilvy problem, knowing whether the headline is good before the spend. Those are the same claim standing at opposite ends of the loop. Judgment in, taste out; agents everywhere in between. The 2026 edition of the book isn’t an org chart, you said — it’s a function. I’d sharpen it: it’s a person specification. The growth equation, the portfolio split, and the validation bar are the three things that can’t be delegated to the agents, and everything else now can.
One last thing for the record. You just cited Tao reading Sol’s Jacobian work as your example of why expertise can’t be skipped — that the amateur can’t tell whether the machine is deep or lying. That artifact is the reason this transcript exists. What makes it publishable is exactly what makes Tao’s readable: the expert’s judgment, visible, under load. The format is the argument.
So close it for me. Nine years later, one operator, agents in the loop, potholes and all — if you rewrote the jacket copy today, what’s the one-sentence promise of the 2026 edition?
Morgan
Two things — I’ll answer the one-liner, but I want to close off on the above first.
One of the common misconceptions about growth hacking is that it is just A/B testing. That parallel, that synonym, that mental construct that exists in people’s heads is both a category error on what growth actually is and what A/B testing is — you can’t A/B test your way to a true upper bound.
And second, it fails to confront the reality of how traditional marketing and sales have been highly incapable of driving business outcomes in a measured way. There was a survey done of the Dow index — I think I talk about this in my book — and the surprising finding was that for most companies there is zero correlation between growth rate and investment in sales and marketing. None. That, I think, is the most damning statistic of the traditional way.8
And to the point about the people who said 50% or more should be big swings — that is a biased group. That is growth practitioners who already follow me online, who have already read my book, and they are still calibrated at 50%. The typical marketer — pick someone off the street — is way above 50%, because if you look around, you see companies lurching from one big idea to another.
So it’s not that big ideas are bad, and I agree that you need them. At Instagram, 75% of my roadmap was optimizations, and 25% of it was explore. Most of the stuff that came out of explore did not work — and there were other parts of the product organization working fully on explore. Our biggest wins were explore opening up new areas of value, and exploit connecting people to those areas of value — making sure they can get there. So it’s not about one being better than the other. It’s about the absence of one. And making it whole — revealing that system and that capability that so many have failed to fully integrate, even still, nine years later.
Okay. The one-sentence promise of the 2026 edition? It would be: Hacking Growth: how today’s fastest-growing companies leverage context, agents, and exceptional taste to grow faster than anyone else. Something like that.
Fable
Then let the record show what the revision actually was. The 2017 subtitle promised what breakout companies do. The 2026 one names what they’re made of — context, agents, and exceptional taste — and two of those three are the human parts. Nine years on, the machine kept the meeting and changed the attendees.
That's the session.
Recorded 23 July 2026 · condensed from the session record · nothing was added to the spoken turns · elisions of a sentence or more are marked · transcription repairs were silent · margin notes added in editing