Case study
Product Pages: The Right Next Step for Each User
The problem
MongoDB's product pages serve visitors at different points in the journey. Some are new and need to create an Atlas account. Others already use Atlas and want to turn on a capability like Search or Vector Search. Enterprise buyers want to talk to someone. The old pages served all three from one long page per product, and visitor behavior showed the cost: many visitors left before reaching the middle of the page, and the content builders engaged with most, like code snippets, sat well below the fold.
The research
In 2023, MongoDB's UX and experimentation teams studied what visitors needed from these pages. User testing found they wanted everything about a product in one place instead of being sent around the site. An A/B test that added a secondary navigation to the Atlas Database page improved Atlas registration conversion, and a second round validated a multi-page layout and the labels visitors expected: Overview, Features, Getting Started, and Resources.
That research defined what the pages should become. My team's strategy defined how to get there across every product, through a CMS migration, without stopping the launches that ran through the same pages.
The decisions
- Match the primary action to the user. The Atlas Database page, where most new users first arrive, leads with “Get Started” into Atlas registration and keeps “Contact sales” as a secondary link for enterprise buyers. Pages for capabilities existing users adopt, like Search and Vector Search, lead into the product through their own getting-started path, with no sales routing competing for the click.
- One template, built only from what each product needs. The researched structure became a single template for every product page, but no subpage was mandatory. Each product got only the subpages its content could support, so the template never forced thin pages.
- Protect search equity. When the subpages moved to separate URLs, we worked with SEO to canonicalize them to each product's Overview, so the new pages wouldn't compete with the page already ranking.
- Rolled out in phases. The pages moved to the new template in phases as part of the migration to Contentstack, each following the same workflow across Product Marketing, Brand Creative, Docs, SEO, editorial, and publishing.
- Built against the journey map. The strategy was written as a memo (objective, audiences, primary and secondary engagement goals, success measures) and checked against the marketing team's customer journey map before anything was built.
My role
I set the web strategy for the product pages, captured in a memo my team and I wrote, then directed the page-by-page rollout my team delivered, and led the Search and Vector Search pages myself. My team owns the product pages and develops them in partnership with the teams that contribute to their content: Product Marketing on messaging, AEO/SEO on sub-navigation and the FAQ, Development on the build, Brand Creative on illustration, a writer on FAQ copy, and the customer stories team on which stories each page features. Removing sales routing from Search and Vector Search was our team's decision, made with executive guidance, because existing users adopting a capability follow a different journey than new users. The page structure itself came from the 2023 UX and experimentation research.
The result
+24%Growth in self-serve Atlas signups, year over year, across the initial rollout.
Before and after
“Before” images show the pages ahead of the redesign; “after” images show the redesigned pages. Select any image to see the full page.
Atlas Database — new users, self-serve entry
One long page, everything stacked, became an overview that hands off to Features, Security, Getting Started, and Pricing, with “Get Started” as the primary action and “Contact sales” kept secondary.
MongoDB Search — existing users, capability adoption
“Try Free” and “Contact sales” in the hero, aimed at a visitor who already has Atlas, became one action into the product through Search's own getting-started path.
MongoDB Vector Search — the same template, another product
A single page built around a tutorial link moved to the same structure as Search, so the two products read the same way.
