Principles
Durable claims that survive beyond the speaker's biography — each with explicit limits, transferability judgment, and evidence.
Principle
Multi-product portfolio with explicit retention-vs-profit role labels
Multi-product expansion is necessary for durability, but the second product needs to come naturally from the first AND each product needs an explicit role (profit OR retention) so that teams build for the right outcome.
Square: 1 product → 11 products each >$50M. North-star metric: median products per merchant. Square Capital was a near-zero-margin product that drove enormous retention because Square owned the payment flows that underwrote it. People said "it's not making money" — that missed the point.
Use when: Companies above $50M ARR planning a second or third product line.
Skip when: Pre-PMF companies where the right move is depth on product 1.
Before launching product N, write down explicitly whether it is profit pool or retention. Communicate the label to the building team.
“You cannot be a single product company and most importantly your product number two needs to emanate very naturally. It can't be like this completely separate product has to be very adjacent.”Gokul Rajaram
“Some products are good for making money, they're part of the profit pool and some are good for retention. Companies be very clear which are the profit pool products and which are the retentive products. If you confuse the two, your teams don't know and they're built for the wrong outcomes.”Gokul Rajaram
Durability: Durable; the role-confusion failure mode is structural across multi-product orgs.
Principle
Multiplayer products carry built-in defensibility — single-player products do not
Multiplayer-by-construction (Facebook, Figma) inherits two structural advantages over single-player products: distribution scales via invitation, and switching costs scale with team size.
Gokul on Facebook: you cannot use it if you only have one person on Facebook. On Figma: the unlock was not just one designer producing — it was easy sharing across the company. Best PLG companies are multi-duplicate-use, which compounds defensibility.
Use when: Founders designing single-player tools that have a plausible team-collaboration variant.
Skip when: Pure individual-use categories where multiplayer adds no value.
Audit your product for a multiplayer mode. If one exists and is not yet wired in, it is the highest-priority defensibility build.
“Most software products are single player and as soon as you make the multiplayer, there is a uniqueness in switching distribution... by nature, you can't use it if you only have one person on Facebook.”Gokul Rajaram
“The best PLD software companies are those that you can use multi duplicate use and it increases defensibility.”Gokul Rajaram
Durability: Durable; the principle generalises across software.
Principle
Remarkable product first — go-to-market does not save a mediocre product
If the core product is not 10-100× better than the alternative on at least one dimension, no GTM stack will scale it durably; products without remarkability decay even with best-in-class distribution.
Gokul: Google taught build-it-remarkably-and-they-will-come. Gmail launched April 1 2003 with 1GB free vs Yahoo Mail at 10MB — a 100× storage delta. Distribution alone cannot fabricate a value-claim that strong.
Use when: Founders pre-PMF deciding whether to scale GTM before the product is remarkable.
Skip when: Late-stage businesses where the moat is now distribution / regulatory and product remarkability is moot.
Audit your product against the 10-100× test on at least one dimension. If you cannot articulate the multiple, do not scale GTM.
“Ultimately my core investing thesis is that if there is not a remarkable product, all the go-to marketing distribution in the world will not save you.”Gokul Rajaram
“This was web email which gave one gigabyte free storage and back then Yahoo Mail offered 10 megabytes of storage, so it was a hundred x.”Gokul Rajaram
Durability: Durable; the core insight has held across decades and product categories.
Principle
Bolt-on AI must reframe what the product DOES — not just add a feature on top of GPT/Claude
A bolt-on that improves margin or adds a checkbox feature stays a checkbox feature; a bolt-on that uses new model capability to invert the product's core interaction (e.g., document-upload → instant insight, not upload-and-wait) becomes a new product.
Notion is reframing positively (AI agents tuned to user behavior). Most bolt-on players are NOT — they put a thin layer on a GPT/Claude call. Document processing six months ago: upload, wait. Now: extract structured info from unstructured docs reliably; the entire upload flow needs to instantly deliver insight while the user is still uploading.
Use when: Existing software companies adding AI features to a legacy core.
Skip when: Pre-existing AI-native products that already use new capability primitives in their core.
Run a per-interaction audit each model release. For each touch, ask: what does the new capability change about how the user experiences this? Reframe before competitors do.
“The companies where the bolt on really works are the ones that reframe what the product does, not just add the capability... if you just add AI search as one thing, you just add AI search or you build search as an experience with new UX primitives, one is just an upgrade, the other is doing completely something completely different.”Gokul Rajaram
“You need to reevaluate every single interaction and say what has changed? That is the biggest difference in product development today.”Gokul Rajaram
Durability: Time-sensitive but the reframe-vs-bolt-on distinction is durable.