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/sellers sell product bundles combining their own software and services with products from other partners/sellers. Each product keeps its own pricing and terms, but the buyer negotiates, evaluates cost, and gets procurement approval through an offerset. It's available across every AWS Region where AWS 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 & discovery

Buyer initial 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, buyers like Allspring, Interface Financial, IHG Hotel and Resorts, HERE Technology and more.

The key finding

• Finding 1: Interest in bundling

  All buyers acknowledged potential value in purchasing multiple products together, particularly for reducing payment overhead and streamlining procurement for same-vendor products.

  • 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

• Finding 2: Separate approvals & legal review are non-negotiable

  • Enterprise customers require individual contract review even in bundled purchases. Each product represents a separate legal agreement that procurement, legal, and security teams must evaluate independently. Bundling at the transaction level does not eliminate the need for separate approval workflows.

• Finding 3: Granular, flexible invoicing required

  • Enterprise buyers need itemized billing with FinOps tagging capabilities, support for phased invoicing across contract terms, and clear visibility into PPA (Private Pricing Agreement) drawdown eligibility per product.

• Finding 4: Independent renewal per product is critical

  • Buyers need the ability to renew, modify, or drop individual products without disrupting the rest of the bundle. Post-purchase, buyers think of products as independent agreements not as a single bundle unit.

This meant SMBs were likely to use the full product bundle journey from 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.

"Well, I like this. I mean, this is really like everything that I would need, bundled together.  I can immediately tell you this case. So let's say that I'm a new customer for AWS, and I need to build a network environment. So for the network environment, I need a central router. I need some kind of VPN Device, or VPN appliance, or whatever. So where do our users actually connect to that VPN appliance? It's an SSL VPN type. So, you establish connection from your laptop, you get that access to the internal network, and from there, that VPN Device, you go to the VPN router, then you can actually go to the Taiwan data center, or go to the US data center, or go to another organization account using VPN and this VPC peering. I bought a solution, not three products.” - Damir, IT manager

Design decisions & leadership

Scoping the MVP

Based on the initial research and product requirement doc, the P0 (MLP) scope centered on three phases of the buyer journey:

1. Discovery — designed multi-product solution detail pages, integrated search and filtering, private-offer-only requests (no public offers in P0), capped at 5 products per solution.

2. Procurement — a consolidated multi-product procurement widget with single-click acceptance across all offers, plus the ability to review individual offers within the offer set.

3. Subscription management — individual product subscription and agreement management, plus a dedicated solution page for the offer set (no changes to fulfillment).

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 usage-based offer, contract offer with a flexible payment schedule (FSP), contract-based offer and free trail offer— 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, working closely with the product and dev team to think through edge cases such as:

• What happens when some product agreements are created but execution fails on the backend? How do we communicate that partial state to the buyer without causing panic or confusion?

• What happens when an offer set is expiring or has already expired?

• What happens when all product agreement creation or approval attempts fail?

• What does the downloaded offer set look like?

For each of these, 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.

One edge case that stands out was specific to Red Hat products. Due to an agreement between Red Hat and AWS Marketplace, Red Hat products are intentionally omitted from display in the Marketplace Console, per the ROSA team's request. This created a gap: if a buyer created an offer set containing ROSA products, that offer set would appear in Private Offers, and the buyer could procure it — but once the resulting agreement was created, there was no trace of it anywhere in the MP Console.

When my dev team flagged this inconsistency, I worked with the team investigating and resolving it. I worked through the actual UI end-to-end to document exactly how this broken state appeared to buyers, identified where the disconnect was happening in the flow, and partnered with the dev team to define how we should represent this case going forward ensuring buyers wouldn't be left without visibility into an agreement they'd already procured.

Designing Multi-Product offer set 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 to a single offer. Customers needed to review each offer individually, make a decision within each one, and then subscribe the offerset. The question was: what interaction pattern supports reviewing and configuring multiple independent offers without overwhelming the buyer?

I explored four layout approaches within the AWS design system:

• 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 the steps can feel long.

• Expandable accordion — all offers on one page, expandable to reveal details. Good overview with progressive disclosure, but the procurement page can get long with many offers.

• Table layout — 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 5, keeping cognitive load manageable throughout.

Final design

Impact

• Launched November 30, 2025

• Presented at AWS re:Invent 2025 main stage (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.