Multi-Product solutions: simplified procurement for bundled offers in AWS Marketplace
Role: Buyer-side lead designer, (collaborated with a UX designer who led seller-side)
Timeline: Launched November 30, 2025
Team: 2 UX designers, 2 dev teams, 2 PMs
Skills: Systems Design, Enterprise UX, Scope prioritization
Multi-Product Solutions is a AWS Marketplace capability that lets partners from independent software vendors to system integrators sell solution-centric bundles combining their own software and services with products from other partners. Each component keeps its own pricing and terms, but the buyer negotiates, evaluates cost, and gets procurement approval through a single point of contact. It's available across every AWS Region where Marketplace operates and supports SaaS, Server, AI Agents and Tools, Machine Learning, and Professional Services product types.
To comply with my non-disclosure agreement, any confidential information is omitted in this case study.
The problem
AWS Marketplace customers increasingly want to buy comprehensive solutions that combine multiple products and services not standalone listings. But AWS Marketplace was built for single-listing transactions, which forced buyers through repeated procurement cycles and sellers through fragmented operational work for what should have been one unified deal.
The pain was sharpest for large sellers booking multi-year enterprise contracts that spanned several business units: they had to coordinate multiple points of contact on both the seller and buyer sides just to close what was conceptually a single deal.
I led buyer-side design on the end-to-end experience needed to fix this: discovery, procurement, and subscription management for bundled, multi-product solutions.
Who this serves
The multi-product solutions ecosystem involves several distinct roles, each with different needs:
Independent Software Vendors (ISVs) — organizations like Salesforce and Red Hat that develop and sell software products through AWS Marketplace
Channel Partners / Consulting Partners — intermediaries like Accenture and Deloitte that connect ISVs with customers, providing implementation and technical expertise
System Integrators (SI) / Global System Integrators (GSI) — technical specialists like Rackspace that integrate solutions with AWS infrastructure
Aggregators — platform providers (e.g., Tackle, Feenix.ai) that enable private marketplaces for direct seller-buyer transactions
Buyer — the end-user or organization purchasing and implementing a Marketplace solution
Multi-product Owner — the lead partner (ISV / Channel Partner / SI / Consulting) responsible for creating and managing a multi-product solution, and serving as its primary owner
Research & insights
Buyer interviews
I ran 10 in-depth buyer interviews across a representative sample of company sizes, from SMB to Enterprise, structured around validating the multi-product solution concept.
Key finding: SMBs showed markedly higher interest in pre-packaged multi-product solutions than enterprise buyers, and were more likely to be early adopters. Two benefits came up repeatedly a streamlined purchasing process, and the ability to address complex business needs without stitching together separate purchases themselves.
User testing
I tested the buyer experience across four rounds of testing on usertesting.com, a mix of moderated and unmoderated sessions. Results were strong: participants showed clear comprehension of the flow, and we saw no significant navigation challenges. Most of the insights from these sessions were incorporated directly into the current design.
SMB vs. Enterprise: different adoption paths
Follow-up research (conducted jointly across UX, Product Management, and Business Development) sharpened this SMB/Enterprise split further:
SMB segment — strong interest in pre-packaged solutions, more willing to be early adopters, higher potential for immediate adoption
Enterprise segment — more conservative adoption approach, stronger preference for existing partner relationships, favors customized private offers through established procurement channels
This meant SMBs were likely to use the full journey — discovery through subscription management — while larger companies would get most of their value from the transaction portion alone, layered onto their existing AWS partner-led sales relationships. Both groups would benefit from the experience and close deals faster.
Design decisions & leadership
Scoping the MVP
Based on the research, the P0 (MLP) scope centered on three phases of the buyer journey:
Discovery — enhanced multi-product solution detail pages, integrated search and filtering, private-offer-only requests (no public offers in P0), capped at 5 products per solution
Procurement — a consolidated multi-product procurement widget with single-click acceptance across all offers, plus the ability to review individual offers within the package
Subscription management — individual product subscription and agreement management, plus a dedicated solution ID page for the package (no changes to fulfillment)
Designing Multi-Product offer display in the procurement widget
Challenge: When a customer subscribes to a multi-product solution, each offer inside it carries distinct terms, pricing, and contract configurations — a 1-month term next to a 24-month term, for instance. Offers couldn't be merged into one view. Customers needed to review each offer individually, make a decision within each one, and then subscribe. The question was: what interaction pattern supports reviewing and configuring multiple independent offers without overwhelming the buyer?
I explored four layout approaches:
Tabbed layout — each offer on its own tab. Clean separation, but hides context of the other offers and makes comparison hard.
Wizard (step-by-step) flow — buyers move through each offer sequentially, ending on a consolidated review page. Reduces cognitive load, but hides upcoming offers and can feel long.
Expandable accordion — all offers on one page, expandable to reveal details. Good overview with progressive disclosure, but the page can get long with many offers.
Split-panel table — all offers in a summary table; selecting one opens a detail panel alongside the table to configure that offer. Maintains overview and detail at once and supports comparison, at the cost of a more complex UI pattern.
Decision: I moved forward with the table approach. It gave buyers a persistent overview of every offer in their subscription while letting them drill into each one, make selections, and track progress across the set. The pattern scaled cleanly whether a solution had 2 offers or 10, keeping cognitive load manageable throughout.
Designing across the full buyer journey: managing complexity at scale
Challenge: The multi-product solutions experience spans the entire buyer journey — discovery, procurement, and subscription management — and each stage introduced its own interaction patterns, offer types, and edge cases. During procurement alone, a single offer set could include standard offers, free-tier offers, free-trial offers, consumption-based contracts, FSP (Fixed Subscription Pricing) plus usage models, and combined contract offers — each with different information architecture needs and different buyer decision points. A one-size-fits-all pattern wasn't going to hold.
Beyond the happy path, I took ownership of the unhappy-path scenarios: what happens when all agreements are technically created but execution fails on the backend? How do we communicate that partial state to the buyer without causing panic or confusion? I designed specific error messaging and recovery flows so the buyer always had clarity on what happened and what to do next.
My process for managing this complexity:
Built a comprehensive use-case matrix cataloging every offer type, state, and edge case across the journey
Maintained constant communication with PMs and engineering, proactively scheduling working sessions to surface hidden technical constraints — many edge cases only became visible through deep collaboration with engineers who understood the backend execution logic
Designed progressively — starting with core happy paths, then layering in edge cases as they were identified, incorporating each new failure scenario into the design system as soon as it surfaced
Final design
Impact
Launched November 30, 2025
Presented at re:Invent 2025 (1M+ views)
Shifted AWS Marketplace from single-listing-only transactions to a composable, multi-product procurement model
Reduced procurement friction for enterprise sellers coordinating multi-year, multi-business-unit contracts
Total Contract Value surpassed $100M in the 7 months since launching in December 2025.
Purchases split 65% SMB to 35% enterprise, though enterprise checkouts averaged a higher dollar value than SMB ones based on metrics through 7/31/2026."
Lessons learned & what I'd do differently
1. Build the use-case matrix upfront — don't discover edge cases reactively.
With so many offer types (free-tier, free-trial, FSP + usage, contract offers) and states (success, partial failure, execution errors), edge cases kept surfacing throughout the process, and many stayed hidden until engineering flagged them mid-development. Next time, I'd invest more upfront time running structured workshops with engineering and PMs to map every offer type × state combination into a design matrix before starting high-fidelity work — turning reactive discovery into proactive coverage.
2. Set evaluation criteria before exploring layout patterns, not after.
For the multi-offer display challenge, I explored four distinct approaches — tabs, wizard, accordion, split-panel — before landing on the right one. The exploration was valuable but time-intensive. In retrospect, I'd define criteria earlier, like "supports 2–10 offers without layout breaking," "allows configuration within each offer," and "maintains overview context," so I could eliminate weaker patterns faster and spend more time refining the strongest candidate.
3. Design for the unhappy path with the same rigor as the happy path, from day one.
Error states like "agreements created but execution failed" needed their own messaging, recovery flows, and UI patterns. I initially focused on core flows and layered error states in later, which sometimes meant reworking layouts to accommodate them. Going forward, I'd treat error and edge-case states as first-class deliverables in initial sprint planning, not afterthoughts, to avoid retrofit work and keep the buyer experience robust even when things go wrong.