How to Build and Operate a Multi-Product SaaS Portfolio

Almost every piece of startup advice tells founders to focus on one product. Almost every large, durable software company eventually stops following that advice. HubSpot didn't stay a single marketing tool. Atlassian didn't stay just Jira. Figma didn't stay just a design tool. And the founder of Basecamp — a company that once literally renamed itself and killed every other product specifically to enforce single-product focus — reversed that decision eight years later and explained, in his own words, exactly why.

This isn't a contradiction. It's a sequencing question that most startup advice skips past: the “focus on one thing” advice is almost always correct for a company that hasn't yet found product-market fit, and becomes progressively less obviously correct once a company has a real, proven, durable first product and is deciding what to do with the operating leverage that success created. This guide covers the real structures multi-product companies use, the honest case for and against building one, how single-product companies actually make the transition, the organizational patterns that determine whether it works, and when adding a second product is the right call rather than a distraction.

This guide is written from a slightly different vantage point than the three before it in this series. Our earlier guides on MVP development, building without a technical co-founder, and choosing a development agency were all written for a founder deciding how to get a first product built. This one assumes that question is already answered — you have a real, working product with real customers — and asks a different one: what should you do with the leverage that success created? Loomstrat itself sits on both sides of this question, running Loomstrat Labs as an independent product portfolio while Loomstrat Studio builds first products for other founders, which is part of why this specific trade-off is worth writing about carefully rather than repeating the generic “focus is everything” advice without examining when it stops applying.

What a Portfolio Model Actually Is

“Portfolio company” gets used loosely enough that it's worth being precise about what you're actually choosing between, because the four real structures covered in this guide carry very different organizational demands.

The 4 Real Portfolio Structures

1. Organic multi-hub expansion

A single company builds or acquires additional products under one brand and one integrated platform, typically sharing a customer base, billing system, and go-to-market motion. HubSpot is the clearest example: starting from a free CRM launched in 2015, the company added Marketing Hub, Sales Hub, and Service Hub, then a CMS Hub in April 2020, according to HubSpot's own company-news announcement (HubSpot, April 2020), and continued expanding — a rebuilt Service Hub, a renamed Content Hub, and a global Commerce Hub were announced together in an April 2024 investor-relations release (HubSpot Investor Relations, April 2024). Atlassian followed a similar organic-plus-acquisition path from Jira and Confluence, adding Trello via acquisition in 2017 and other tools since, explicitly to expand the budget it could capture from the same customer base — a strategy a16z's own analysis frames directly: “Atlassian continues to expand addressable customer budget on the same growth+sales motion by delivering more value to the same customers, both via inorganic growth as a prolific acquiror... and by organically adding surface area to the product suite” ( a16z, “Growth+Sales: The New Era of Enterprise Go-to-Market,” July 2020).

What makes this structure specifically powerful, and specifically demanding, is the shared customer base. A HubSpot customer already logged into Marketing Hub can be shown Sales Hub without a separate signup, a separate sales conversation, or a separate trust decision — the cross-sell motion rides on top of a relationship the company has already earned. That's the leverage. The demand it creates is that every product in the suite now shares reputational risk with every other one: a serious quality problem in one Hub doesn't stay contained to that Hub's customers, because it's the same account, the same login, and often the same buyer evaluating all of them together. Organic multi-hub expansion only works as well as the company's ability to maintain a consistent quality bar across every product wearing the same name.

This is also the structure best suited to a company whose sales motion already involves a single buyer evaluating a bundle of needs at once — a marketing lead choosing between martech vendors, or an engineering lead choosing a project-management stack — since the additional products can be presented as a single, coherent decision rather than several separate purchases the buyer has to justify independently. It's a weaker fit for a company whose first product serves a buyer with a narrow, single-purpose need, since bundling unrelated capability into that buyer's decision adds friction rather than value.

2. Independent portfolio operation

One parent operates multiple, largely independent products that don't necessarily share a brand or a customer base, but do share capital, some operating infrastructure, and management attention. Andrew Wilkinson's Tiny is the clearest modern example — a holding company that has built, bought, or invested in dozens of internet and software businesses over roughly fifteen years, described in Wilkinson's own words in a detailed interview on Lenny's Newsletter (Lenny's Newsletter, “I've Run 75+ Businesses,” Andrew Wilkinson interview). This is the model Loomstrat Labs itself runs — a portfolio of independently operated products under one parent, rather than a single integrated suite.

The trade-off here runs in the opposite direction from organic multi-hub expansion. Without a shared brand or customer base, each product in an independent portfolio has to earn its own trust, its own distribution, and its own product-market fit essentially from scratch — there's no free cross-sell the way HubSpot gets one Hub's customer into another. What the parent company gains instead is insulation: a serious problem with one product doesn't automatically damage the reputation of the others, since most customers of any one product never interact with, or even know about, the rest of the portfolio. That insulation is exactly why this structure suits genuinely unrelated products better than the organic multi-hub model does — there's no requirement that the products serve the same customer or even the same category.

What replaces the shared customer base as the source of leverage in this structure is shared operating knowledge and capital allocation discipline — the parent company gets better over time at recognizing which products are worth funding further, which need a change in direction, and which should be sold or shut down, purely from having run several products through that same decision process before. This is a subtler form of leverage than HubSpot's cross-sell, but it compounds in its own way: the fifth product a portfolio operator launches typically benefits from lessons the first four already paid to learn, even without sharing a single line of code or a single customer relationship between them.

3. Startup studios

A studio originates and builds multiple, fully independent companies — each typically with its own cap table, brand, and often its own outside CEO — rather than operating them under one roof. This is structurally distinct from the other three: the studio itself doesn't operate the products long-term, it spins them out. Science Inc., an LA-based studio founded in 2011, spun out roughly 75 companies in its first round, with Dollar Shave Club — acquired by Unilever for a reported $1 billion in 2016 — as its most prominent exit. Atomic, founded by Jack Abraham in 2012, uses a similar model, recruiting outside operators to run companies it originates; its most prominent result, Hims & Hers, went public in 2021.

This is the structure to rule out explicitly if what you actually want is Loomstrat Labs's model — a studio, by design, doesn't retain the products it originates. It exists to originate, fund, and hand off, which makes it the right structure for an investor or serial builder who wants to keep starting new things without operating any of them long-term, and the wrong one for an operator who wants to build and keep a portfolio of products they continue running themselves.

4. M&A holding companies

A public or private holding company acquires existing, already-profitable software businesses and lets them continue operating with significant autonomy, rather than building products in-house. Constellation Software (TSX: CSU) is the defining example, having acquired more than 1,000 businesses through six operating groups, run by what founder Mark Leonard has described in his own shareholder letters as a small corporate office acting as “a good owner of hundreds (and perhaps someday thousands) of growing autonomous small businesses that generate high returns on capital” (Constellation Software, Letters to Shareholders). Vista Equity Partners runs a related but philosophically opposite version of this model: rather than holding companies indefinitely with radical operating autonomy, Vista standardizes acquired companies against an internal “Vista Best Practices” playbook and typically exits them within a private equity fund's five-to-seven-year lifecycle. Two real companies, both managing dozens to over a thousand software businesses, arriving at opposite conclusions about how much central control a portfolio needs — itself useful evidence that this question doesn't have one universally correct answer.

None of these four structures is mutually exclusive with the others over a company's lifetime, and it's worth noticing how often real companies move between them rather than picking one permanently. A studio-originated company can grow into an organic multi-hub company once it has its own durable first product. An independent-portfolio operator can acquire a struggling product and fold it into one of its existing companies rather than running it standalone. The 37signals story later in this guide is itself an example of movement along this spectrum — from a company that briefly resembled an independent portfolio (Basecamp, Highrise, Backpack, and Campfire, each fairly distinct) to strict single-product focus, and later to a tighter two-product structure closer to organic multi-hub. The structures in this guide describe a company's current shape, not a permanent identity.

The Case for Multiple Products

The strongest arguments for a portfolio model are about leverage, not just diversification. Once a company has built real infrastructure — billing, authentication, a support organization, brand trust with a customer base — a second product built on that same foundation costs meaningfully less than the first one did, and reaches customers who already trust the brand. Intercom's own engineering blog describes the operational logic behind this directly, in the context of explaining why it built a dedicated internal platform team: “This surfaced as an increasingly large percentage of our product teams' time being spent on operations or deep diving into understanding our small set of core technologies” ( Intercom, “Scaling Our Core Technologies Team,” Ryan Sherlock, May 2021) — the same shared-infrastructure logic that makes a second product cheaper once the first one has already paid for the plumbing.

“We continue to believe that autonomy and responsibility attract and motivate the best managers and employees.”

— Mark Leonard, Constellation Software, 2015 Letter to Shareholders

Diversification is the second real argument, though it's worth being precise about what it actually protects against. A single-product company's entire revenue depends on one market's continued demand, one competitive landscape, and one product's continued execution. A portfolio spreads that dependency across multiple products, markets, and teams — not eliminating risk, but making the company's survival independent of any single product's trajectory. This is closer to how Constellation Software and Vista think about risk at the holding-company level than how a typical SaaS founder thinks about a second feature, and it's a genuinely different kind of resilience than feature diversification within one product provides.

There's a third, less-discussed argument worth naming: talent retention. A company with only one product has a natural ceiling on how many senior, ambitious people it can keep engaged long-term — eventually, a talented product lead or engineer runs out of new problems to solve within a single product's scope. A portfolio, whichever structure it takes, gives a growing company a second and third arena to put its best people in charge of, without those people needing to leave to find a bigger challenge elsewhere. This is part of why Constellation Software's own letters emphasize autonomy so heavily — a structure that hands real ownership to operators inside a portfolio is also a retention strategy, not just a growth strategy.

The Case Against It

The strongest argument against building multiple products isn't really about SaaS specifically — it's about attention, and it predates the multi-product SaaS conversation entirely. Paul Graham's 2010 essay on founder focus makes the underlying case, even though it's not written about product strategy directly: “I think most people have one top idea in their mind at any given time... Which means it's a disaster to let the wrong idea become the top one in your mind” (Paul Graham, “The Top Idea in Your Mind,” 2010). Applied to a second product: every hour spent thinking about Product B is an hour not spent making Product A's core value proposition sharper, and a founder with two “top ideas” competing for the same finite attention often ends up giving neither the depth either deserves.

Organizational complexity is the second real cost, and it compounds faster than founders typically expect. Two products don't just mean two roadmaps — they mean two sets of customer feedback loops, two support queues, two sets of pricing decisions, and, if the products share any infrastructure at all, an ongoing negotiation over whose priorities that shared infrastructure serves this quarter. Vista Equity Partners and Constellation Software both exist specifically to solve this problem at scale, and they've arrived at opposite solutions — heavy central standardization versus radical autonomy — which is itself evidence that the problem is real and doesn't have an obvious default answer.

Brand dilution is the third real risk, and it's most acute in the organic multi-hub structure specifically, since that's the model where every product shares one name. A second product that underperforms doesn't just underperform quietly — it becomes evidence, in existing customers' minds, about the quality of everything else carrying the same brand. This is a genuinely different risk profile than a single-product company faces, where a feature that doesn't work can be quietly improved or removed without becoming a referendum on the whole company. A founder considering organic expansion specifically should weigh this risk more heavily than a founder considering an independent-portfolio structure, where a struggling product carries its own name and its own reputational consequences.

37signals: Both Sides of the Same Bet

No company has documented this trade-off more honestly, in its own words, from both directions, than 37signals — the company behind Basecamp.

In February 2014, the company — then running multiple products including Basecamp, Highrise, Backpack, and Campfire — renamed itself from 37signals to Basecamp and killed every product except its namesake, a deliberate, public bet on single-product focus (Forbes, Feb. 2014). For eight years, that focus defined the company.

Then, on May 3, 2022, founder Jason Fried reversed it — publicly, in his own words, on the company's own blog, renaming the company back to 37signals to reflect a second major product, HEY (an email service launched in 2020):

“Calling our company Basecamp just doesn't make a lot of sense when we make more than just Basecamp... We aren't a one product company anymore. We're two. Basecamp and HEY... 37signals makes Basecamp, 37signals makes HEY, and 37signals will make more products soon, too.”

— Jason Fried, 37signals, May 3, 2022

Read together, these two decisions — eight years apart, both made publicly and explained in the founder's own words — are the single best real-world illustration of the thesis of this whole guide. The 2014 decision wasn't wrong; the company needed to prove Basecamp could be a durable, category-defining product on its own, and diluting attention across four products was actively getting in the way of that. The 2022 decision wasn't a reversal of that lesson — it was evidence that once Basecamp had unambiguously succeeded on its own, the company had earned the operating leverage, brand trust, and organizational maturity to take on a second product deliberately, rather than by accident. The mistake to avoid isn't choosing multi-product or single-product — it's choosing either one before the company is actually ready for the trade-offs it demands.

It's also worth noting what stayed constant across both decisions: 37signals's reputation for building small, opinionated, well-crafted software. The 2014 name change and the 2022 name change were both, in a real sense, about protecting that same underlying identity — first by refusing to let it get diluted across too many mediocre products, and later by explicitly naming the parent company after the fact that it now made more than one great product rather than pretending otherwise. Companies that treat “focus” and “portfolio” as a fixed, permanent identity rather than a decision to revisit as circumstances change miss the actual lesson of this story — which is that the right structure is a function of where the company actually is, not a philosophy to commit to forever.

How Single Products Become Portfolios

Most successful multi-product companies didn't start that way. The more common and generally safer path is expanding an already-proven single product, rather than launching multiple products from day one.

Figma's expansion followed this shape closely: starting as a single collaborative design tool, it added FigJam (a whiteboarding product), then Dev Mode, then further products including Figma Slides, announced together with several others at Figma's Config 2025 event, according to the company's own blog post (Figma, Config 2025 press release, May 2025). Notion followed a similar pattern more recently, launching a standalone Notion Calendar in January 2024 (built on the Cron app, which Notion had acquired in 2022) and Notion Mail in April 2025 (built on Skiff, acquired in 2024) — both reported directly by Notion's own release notes and confirmed by TechCrunch's coverage of the Calendar launch (TechCrunch, January 2024). In both cases, the second and third products arrived only after the first had become a genuinely durable, widely adopted product in its own right — not as a hedge against the first product's uncertainty.

Notice, too, that both Notion Calendar and Notion Mail arrived by acquiring an existing, already-working product (Cron and Skiff respectively) rather than building the second and third products from a blank page internally. This is a distinct, common variant of Stage 4 worth naming on its own: acquiring a proven product and integrating it into an existing brand and customer base, rather than incubating a new one internally from scratch. It carries a different risk profile — you're buying a team and a product that already works, at the cost of an acquisition, rather than betting internal time on an unproven new build — and it's the mechanism behind a meaningful share of the organic-expansion examples in this guide, including several of Atlassian's additions.

Organizing Around Multiple Products

The organizational question every multi-product company eventually has to answer is the same one Intercom's engineering team documented directly: how much should be shared, and how much should each product team own independently?

Atlassian's answer, described across its own engineering blog, is a shared internal cloud platform — an internal PaaS the company calls Micros, built on AWS — that every product team builds on top of, alongside shared CI/CD infrastructure supporting well over a thousand developers across its product lines. The logic is the same one Intercom names explicitly: without a dedicated team owning shared infrastructure, every product team ends up quietly re-solving the same plumbing problems — authentication, billing, deployment — instead of spending that time on what makes their specific product better.

The independent-portfolio and M&A holding-company structures face a related but distinct version of this question, since their products typically don't share a customer-facing platform at all. Constellation Software's radically decentralized model resolves it by deliberately choosing not to centralize most operations — each acquired business keeps its own systems, its own management, and largely its own way of working, with the parent company providing capital and high-level oversight rather than shared infrastructure. Vista Equity Partners resolves the same question in the opposite direction, imposing standardized operating practices (its own “Vista Best Practices” playbook) across every portfolio company specifically to capture efficiency gains a fully decentralized model would leave on the table. Neither approach is more correct in the abstract; each is a coherent answer to the same underlying question, chosen deliberately and applied consistently, which is the actual pattern worth copying regardless of which specific answer a given company lands on.

1. 1

   Decide what’s genuinely shared vs. product-specific

   Billing, authentication, and core design systems are almost always worth centralizing. Product logic, roadmap, and customer relationships almost always work better owned by a dedicated team per product.

2. 2

   Give a shared-infrastructure team its own mandate, not leftover time

   Intercom’s own experience shows what happens without this: shared-infrastructure work quietly consumes product teams’ time instead of being someone’s actual job.

3. 3

   Keep product teams small and accountable for outcomes, not just output

   A model where each product has its own PM, design, and engineering ownership — the shape both Atlassian and Intercom describe — keeps decisions close to the people who understand each product’s specific customers.

4. 4

   Resist premature centralization

   Sharing infrastructure between two products before either one has proven durable creates coordination overhead for a hypothetical future benefit — wait until the shared need is real and specific, not anticipated.

The Economics: Focus vs. Diversification

This is an area where it's more useful to be honest about what isn't known than to repeat confident-sounding numbers that don't hold up under scrutiny. The specific SaaS-focused expansion-revenue percentages that circulate widely in industry content — claims about exactly what share of new revenue comes from cross-sold products at scale — trace back to survey reports that update yearly and are frequently cited without specifying which year's edition the number came from. Rather than repeat an unattributed figure, the more defensible takeaway is structural: the conglomerate discount is a real, academically documented phenomenon in general corporate finance, it reflects real costs (harder to evaluate as an investor, harder to manage as an operator, less obvious a growth story to tell), and whether a specific software portfolio avoids it depends far more on execution — Constellation Software's decades of consistent capital discipline, for instance — than on the portfolio structure itself.

For a private, founder-owned company that isn't raising from institutional investors or planning a public listing, the conglomerate-discount question is largely academic anyway — it's a public-markets valuation phenomenon, driven by how outside analysts and investors price a business they can't fully see inside of. A founder who owns their portfolio outright and has no plans to sell shares to outside investors on public markets is optimizing for cash flow and durability, not for how a hypothetical analyst would model the business — which is a meaningfully different set of incentives than the ones the academic literature on conglomerate discounts was built to describe. The question worth asking instead is a simpler one: does running these products together actually produce more value, more resilience, or a better allocation of your own attention than running them as separate companies would? If the honest answer is no, the portfolio structure isn't earning its complexity, regardless of what any valuation study says about public conglomerates.

When to Add a Second Product

The 37signals story above gives the clearest real-world signal: add a second product once the first one is genuinely durable, not as insurance against the first one's uncertainty. A few more specific signals worth weighing together, rather than any single one in isolation:

• Your core product has stopped requiring your full attention to keep growing. If the first product still needs constant founder-level intervention to hit its numbers, a second product competes directly for the attention Paul Graham's essay warns against splitting.
• You have infrastructure a second product would genuinely reuse. Billing, auth, a support team, brand trust with a relevant customer base — if a second product would need to rebuild all of this from scratch anyway, you don't yet have the leverage that makes a portfolio cheaper than a second standalone company would be.
• The opportunity is adjacent, not identical, to your first product's customer need. HubSpot's Hubs and Figma's expansion both added products solving genuinely different problems for an overlapping customer — not thinner variations of the same core feature.
• You can name who owns the second product, distinct from who owns the first. If the same small team is expected to run both products at once, you likely don't yet have the organizational capacity a second product needs to get a fair shot.

It's worth stress-testing a second product idea against the specific structure you'd use to run it, not just the idea in the abstract. An idea that's a natural fit for organic multi-hub expansion — solving an adjacent problem for the exact same buyer — might be a poor fit for independent-portfolio operation, where the lack of a shared customer base means that same idea has to win its own distribution from zero. Conversely, an idea serving a genuinely different customer than your first product might dilute your brand if forced into the same product suite, but work well as an independently branded addition to a portfolio. Matching the idea to the right structure, rather than defaulting to whichever structure your company already happens to use, is itself part of the decision.

Mistakes Portfolio Operators Make

• Adding a second product to hedge against the first one's uncertainty. This inverts the pattern every credible example in this guide follows — expansion should follow proof, not substitute for it.
• Under-resourcing shared infrastructure until it becomes an emergency. Intercom's own account shows what happens when this is left informal: product teams quietly absorb the cost until it's large enough to demand a dedicated team.
• Centralizing everything, or nothing, instead of choosing deliberately. Both Constellation's radical autonomy and Vista's heavy standardization work, because each company chose one model on purpose and executed it consistently — inconsistency between the two is worse than either extreme.
• Letting a struggling second product drain attention from a healthy first one. The 2014 37signals retrenchment is the clearest documented example of correcting this before it became fatal — recognizing sprawl and cutting it, rather than letting sunk cost keep every product alive.
• Assuming brand trust transfers automatically to an unrelated product. The organic multi-hub examples in this guide all expanded into adjacent problems for the same customer, not unrelated markets where the original brand carries little weight.

Every mistake on this list shares the same underlying cause as the mistakes covered in our earlier guides on hiring and building: skipping the deliberate decision in favor of momentum. A second product added because it seemed exciting, or because a competitor announced one, or because growth had slowed and something needed to change, is being added for the wrong reason regardless of how good the product idea itself might be. The examples that worked in this guide — HubSpot, Atlassian, Figma, Notion, and 37signals' own second attempt — all share a founder or leadership team that could articulate, specifically, why the second product made sense at that particular moment. If you can't yet articulate that as clearly as Jason Fried did in his own 2022 post, that's worth treating as a signal in itself.

Frequently Asked Questions

If there's one practical test worth applying before adding a second product, it's this: could you write the same kind of clear, specific explanation Jason Fried wrote in his May 2022 post — naming exactly what the first product proved, exactly what the second product needs from the company that the first one already has, and exactly who will own each one going forward? If that explanation writes itself easily, the decision is probably sound. If it takes real effort to construct a convincing version, that difficulty is informative in itself — it usually means the real reason for adding a second product is closer to restlessness, competitive anxiety, or a plateauing first product than to the kind of earned leverage every credible example in this guide actually rests on.

The through-line across every real example in this guide — HubSpot, Atlassian, Figma, Notion, Tiny, Constellation Software, and 37signals' own documented reversal — is that a portfolio isn't a strategy you adopt instead of focus. It's what focus eventually earns the right to become, once a first product has proven durable enough to fund and justify a second. Building a portfolio before earning that isn't diversification. It's the same attention problem Paul Graham described, just spread across more roadmaps.