You built a great product.

Customers love it. Revenue is growing. Now you're launching a second product.

Different buyer. Different use case. Different pricing. But same company.

Your marketing team asks: "Do we need a separate website?"

Your CEO says: "Just add a page."

Both answers are wrong.

I've watched dozens of SaaS companies butcher this transition. Single-product sites that worked perfectly become confusing messes when product two launches.

Navigation gets cluttered. Messaging gets muddled. Conversion rates tank across both products.

The problem isn't that you added a product. It's that your website architecture wasn't built to scale.

Let me show you how to do this right.

‍

Why single-product architecture breaks at scale

Your first product's website was simple.

Homepage explains the product. Features page shows capabilities. Pricing page shows one set of plans. Everything is about that one thing.

This works great. Until it doesn't.

Product two launches. Now you have two audiences. Two value props. Two use cases. Two pricing pages.

What do you do?

Most companies do this: Shove product two into the navigation. Add "Product 1" and "Product 2" dropdowns. Create duplicate page structures. Hope people figure it out.

Result: Nobody understands what your company does anymore.

Homepage tries to be about both products. So it's specific about neither. Navigation is confusing. Visitors from Google land on product-specific pages and never understand the broader platform.

Real example: A company had a time-tracking product. Added project management.

Their homepage became: "Time tracking and project management for teams."

Vague. Generic. Conversion dropped 31%.

Why? Because someone searching for time tracking software doesn't care about project management. And vice versa.

By trying to be both, they became neither.

The architecture that got you to $10M ARR won't get you to $50M.

You need to think differently about structure.

‍

The three multi-product architecture models that actually work

There are three proven approaches. Which one fits depends on your products' relationship.

Model 1: Platform + Products (Integrated Suite)

Use when: Your products work together as a unified platform. Customers often buy multiple products. Strong cross-sell dynamics.

Examples: HubSpot (Marketing + Sales + Service Hub), Atlassian (Jira + Confluence + etc), Microsoft 365

Structure:

• Homepage: Platform-level messaging and value prop
• Product pages: Individual product detail and positioning
• Use case pages: How products work together for specific scenarios
• Unified pricing: Bundle pricing and multi-product deals

Navigation: Platform positioning first, products secondary.

Model 2: Product Suite (Related but Independent)

Use when: Products solve related problems for similar buyers. Can be sold independently. Light integration but not required.

Examples: Salesforce (Sales Cloud + Marketing Cloud + Service Cloud), Adobe Creative Cloud, Zoom (Meetings + Phone + Rooms)

Structure:

• Homepage: Company mission and vision, not specific products
• Product-specific landing pages: Independent positioning and messaging
• Solutions pages: Industry or role-based bundles
• Separate pricing: By product, with bundle discounts

Navigation: Products as equal-weight primary navigation items.

Model 3: Multi-Brand (Different Markets)

Use when: Products serve completely different audiences. Separate brands and positioning. Little to no overlap.

Examples: Intuit (QuickBooks + TurboTax + Mint), Facebook → Meta (Facebook + Instagram + WhatsApp)

Structure:

• Corporate homepage: Company story, portfolio view
• Separate microsites or full sites: For each product
• Minimal cross-linking: Each product stands alone
• Independent everything: Branding, messaging, pricing

Navigation: Corporate site links to product sites.

Most companies should choose Model 1 or 2. Model 3 is rare and expensive.

‍

How to restructure navigation without breaking everything

Navigation is where most companies screw this up.

Single-product nav: [Product] [Features] [Pricing] [Resources] [Company]

Simple. Clear. Everyone understands it.

Then product two launches and companies do this: [Products ▼ (Product 1, Product 2)] [Features ▼ (P1 Features, P2 Features)] [Pricing ▼ (P1 Pricing, P2 Pricing)]

Disaster. Cognitive overload. No clear path forward.

Better approach depends on your model:

For Platform + Products (Model 1):

Primary Nav: [Platform] [Solutions ▼] [Customers] [Pricing] [Resources]

Platform page explains the unified value prop.

Solutions dropdown has use-case pages that naturally mention which products are relevant.

Pricing shows platform bundles with product add-ons.

Individual products are featured on Platform page, not primary nav. Products serve the platform story.

Example: HubSpot doesn't have "Marketing Hub" in primary nav. They have "Software" which leads to platform overview, then drill down to hubs.

For Product Suite (Model 2):

Primary Nav: [Products ▼ (Product A, Product B, Product C)] [Solutions ▼] [Pricing] [Resources]

Products dropdown shows all products clearly.

Each product has its own complete section (features, use cases, pricing).

Solutions page shows how products combine for specific scenarios.

Pricing can be by product or unified depending on sales motion.

Example: Zoom has Products dropdown (Meetings, Phone, Events, Rooms). Each is independent but related.

For Multi-Brand (Model 3):

Corporate site: [Our Brands] [Company] [Investors] [Careers]

Each brand: Full independent navigation

Minimal connection between sites beyond footer link to corporate.

Example: Meta corporate site links to Facebook.com, Instagram.com, WhatsApp.com. Each has completely independent navigation.

The key: Clarity over cleverness.

Visitors should know within 3 seconds: What does this company do? Which product is relevant to me? Where do I go next?

If your navigation requires thinking, it's wrong.

‍

Homepage strategy when you have multiple products

Single-product homepage: Hero section about the product. Benefits. Social proof. CTA to try or buy.

Multi-product homepage needs different structure.

Bad multi-product homepage:

"We have Product A and Product B for various use cases."

This tells me nothing. I don't know which product I need. I don't understand the relationship.

Good multi-product homepage (Platform model):

Section 1: Platform-level value prop - "The complete workspace for [target customer]. Everything you need to [outcome] in one place."

Section 2: How it works / Core capabilities -Show the integrated value. Don't list products yet.

Section 3: Product showcase - "Powered by three integrated products:" Brief intro to each with link to learn more.

Section 4: Use cases or solutions - "Teams like yours use [Platform] to:" Show scenarios that use multiple products.

Section 5: Social proof - Customers using the platform, with metrics.

Section 6: CTA - Start with platform, choose products later in signup flow.

Good multi-product homepage (Product Suite model):

Section 1: Company mission - "We help [audience] solve [problem category]." Not product-specific.

Section 2: Product showcase - Featured products with clear differentiation. "Product A is for [use case]. Product B is for [different use case]."

Section 3: Who we serve - Industries or roles, with relevant products called out for each.

Section 4: Social proof - Broad customer base using various products.

Section 5: Multiple CTAs - One for each product, or "Talk to sales" to discuss needs.

Real example: Atlassian's homepage doesn't say "We have Jira and Confluence and Trello."

It says: "Atlassian unleashes the potential of every team." Then shows how teams collaborate and deliver using the platform.

Products are featured. But platform value is the hero.

When they added Trello (acquisition), it slotted into this structure naturally. No confusion about what the company does.

Pricing page architecture for multiple products

Pricing gets complicated fast with multiple products.

Single product: One page. Three tiers. Done.

Multiple products: Do you have one pricing page or separate pages per product? Do you show bundles? How do you handle different pricing models?

Decision framework:

Use unified pricing page when:

• Products are sold as platform
• Strong bundle discounts exist
• Most customers buy multiple products
• Sales motion is platform-first

Structure: Show platform pricing with products included at each tier. Add-ons available for specific products.

Example: Monday.com shows workspace pricing with all products included.

Use separate pricing pages when:

• Products are independent
• Different pricing models (seat-based vs usage-based)
• Different buyer personas with different budgets
• Products can be purchased separately

Structure: Pricing page selector or separate pages linked from product pages.

Example: Zoom has separate pricing for Meetings, Phone, Events. Different models, different buyers.

Use configurator when:

• Complex bundling options
• Enterprise buyers need custom combinations
• Lots of add-ons and modules

Structure: Interactive pricing calculator or "Contact sales."

Example: Salesforce has configurator for complex multi-product enterprise deals.

Common mistake: Trying to show everything on one page.

If you have 3 products with 3 tiers each, that's 9 pricing options. Plus add-ons. Plus bundles.

Nobody can process that. You've just made buying impossible.

Better: Start with "Which product do you need?" Then show pricing for that product. With option to add others.

Or: Show platform bundles. With option to buy products separately.

Guide the buyer. Don't dump all options on them.

‍

How to handle product-specific content and SEO

You need content for each product. But how do you structure it?

URL structure options:

Option 1: Subfolder per productyourcompany.com/product-a/yourcompany.com/product-b/

Pros: Clear structure. Easy for users and search engines to understand.Cons: Can feel disconnected from main site.

Option 2: Unified structure with product contextyourcompany.com/features/ (shows platform features)yourcompany.com/features/product-a/ (product-specific)

Pros: Maintains site hierarchy. Shows relationship.Cons: Can get deep and confusing.

Option 3: Separate subdomains
product-a.yourcompany.comproduct-b.yourcompany.com

Pros: Complete independence. Good for acquired products.Cons: Splits SEO authority. Feels like different companies.

Most companies should use Option 1 or 2. Option 3 only for true multi-brand strategy.

SEO implications:

Each product needs its own keyword targeting and content.

Product A: "time tracking software" + related keywordsProduct B: "project management software" + related keywordsPlatform: "team productivity platform" or category-defining terms

Don't cannibalize yourself. Product pages target product keywords. Platform pages target broader terms.

Content strategy:

• Product-specific blog posts tagged to that product
• Use case content that spans products
• Comparison content addressing competitive set per product
• Shared resources (ebooks, webinars) at company level

Create content hubs for each product. Link between them where natural.

‍

Technical implementation and CMS structure

Your CMS needs to support multi-product architecture.

Requirements:

Product taxonomy - Ability to tag content by product. Filter navigation by product. Show product-specific content automatically.

Template flexibility - Product page templates that share components but allow customization. Pricing page templates that adapt to different models. Navigation that changes based on context.

Content reuse - Shared components (testimonials, CTAs, footers). Product-specific versions of components. Easy updates across multiple product sections.

Analytics and tracking - Product-level conversion tracking. Cross-product journey analysis. Product-specific form routing.

Permissions - Product teams can edit their sections. Marketing can edit shared sections. Controlled publishing workflow.

Most companies use:

Webflow: Good for 2-3 products. CMS collections for products. Limited for complex multi-product scenarios.

WordPress: Flexible with custom post types and taxonomies. Can get messy at scale. Requires developer maintenance.

Contentful/Contentstack (Headless): Best for complex multi-product. Expensive. Requires development resources.

Sitecore/Adobe Experience Manager: Enterprise. Overkill for most SaaS until $100M+ ARR.

Pick based on: number of products (2-3 or 5+?), rate of change (launching products often?), team capabilities (need developers or want marketing control?), and budget ($5K/month or $50K/month?).

Don't over-engineer early. But don't pick something you'll outgrow in 6 months.

‍

Migration strategy when transitioning from single to multi-product

You can't flip a switch. This transition takes planning.

Phase 1: Audit and plan (Month 1)

Map current content and pages. Identify what's product-specific vs company-level. Decide on architecture model (Platform, Suite, Multi-brand). Plan new IA and navigation structure.

Phase 2: Build new structure without disrupting current site (Month 2-3)

Create new product landing pages. Build out second product section. Set up new navigation structure. Keep current site fully functional.

Test with users. Validate the structure makes sense.

Phase 3: Content migration and optimization (Month 3-4)

Move content to new structure. Update internal links. Rewrite homepage and key pages for new positioning. Create redirect maps for changed URLs.

Phase 4: Launch and monitor (Month 4)

Launch new structure. Implement redirects. Monitor traffic and conversions closely. Gather user feedback.

Iterate based on data.

Phase 5: Optimize (Month 5-6)

A/B test navigation options. Refine messaging based on product. Fix conversion leaks. Build out missing content.

Timeline: 4-6 months for proper multi-product transition.

Don't rush it. A botched migration tanks conversion for both products.

Real example: Company tried to do this in 2 weeks. Launched broken navigation, confused messaging, mobile issues.

Organic traffic dropped 40%. Conversion rate dropped 35%. Took 4 months to recover.

Proper planning would've avoided all of it.

‍

Common mistakes that kill conversion

I've seen these repeatedly. Avoid them.

Mistake 1: Making every page about every product

Every page mentions both products. Nothing is focused. Conversion tanks because nobody gets clear value prop.

Fix: Product-specific pages are about that product only. Platform pages can reference both.

Mistake 2: Unclear product differentiation

"Product A does X and Y. Product B does Y and Z." Overlap is confusing.

Fix: Clear positioning. "Product A is for [use case]. Product B is for [different use case]." Different problems.

Mistake 3: No clear entry point for visitors

Homepage says "we have products" but doesn't help visitors choose.

Fix: Guide them. "Are you looking to [outcome 1] or [outcome 2]?" Then route accordingly.

Mistake 4: Separate everything too much

Products feel like different companies. No connection. Lost cross-sell opportunity.

Fix: Maintain brand consistency. Show how products complement each other.

Mistake 5: Over-complicating navigation

Dropdowns within dropdowns. Mega-menus. Nobody can find anything.

Fix: Maximum 2 levels deep. Clear labels. Obvious paths.

Mistake 6: Neglecting mobile

Multi-product navigation is already complex. On mobile it becomes impossible.

Fix: Mobile-first design for navigation. Consider different mobile nav structure.

Mistake 7: Pricing confusion

Can I buy products separately? Do I need both? What's the bundle cost?

Fix: Clear pricing paths. Configurator or guided selling for complex scenarios.

Test your structure with real users. If they're confused, fix it.

Conversion data tells you where the problems are.

‍

When to keep products separate vs integrate

Sometimes the answer is: Don't try to integrate.

Keep products separate (different sites/brands) when:

Completely different target audiences (B2B vs B2C). Different brand positioning or personality. Acquired product with established brand. Different go-to-market motions. Potential to sell/spin off later.

Integrate into single architecture when:

Same target audience or buyer. Complementary use cases. Strong cross-sell opportunity. Shared brand benefits both products. Operational efficiency from integration.

Most SaaS companies should integrate. Separate sites make sense for major acquisitions or fundamentally different markets.

Example: When Salesforce acquired Slack, they kept it as Slack.com. Different brand, different audience, different everything.

But Salesforce's own products (Sales Cloud, Marketing Cloud) are integrated into salesforce.com architecture.

Context matters.

‍

The uncomfortable truth about scaling

Adding products is messy.

Your beautiful, simple website becomes complex. Navigation gets harder. Messaging requires more nuance. Some conversion rate drop is inevitable during transition.

That's okay. You're not optimizing for elegance anymore. You're optimizing for growth.

Companies that nail multi-product architecture: Show clear value at company level. Make it easy to understand each product. Guide buyers to the right solution. Maintain cross-sell opportunities. Keep brand cohesion.

Companies that botch it: Confuse everyone about what they do. Make navigation impossible. Dilute messaging trying to be everything. Kill conversion across all products.

The difference is intentional architecture planning.

Not just "add another page."

Start with structure. Build for scale. Test with users. Iterate based on data.

Your second product is a huge opportunity. Don't kill it with bad architecture.