CS 02: Onboarding & Listing Creation for AWS Marketplace
How a 2–3 month, support-heavy AWS listing process became
a self-serve workflow completable in under a week.
My role:
End-to-end product design and ownership. Sole designer and first design hire. Problem definition, system architecture, interaction design, and final execution across two years of continuous iteration. Worked directly with founders and PMs on scope, with dev and QA on every shipped surface, and with users on every iteration. Built the design system from scratch, then mentored juniors into contributing as the team grew.
The Problem:
Getting listed on AWS Marketplace took 2-3 months of back-and-forth between the customer, CS, PMs, and developers. From support tickets, customer calls, and ISVs actively trying to create listings, the same patterns kept surfacing.
Missing prerequisites users didn't know existed
AWS terminology with no in-context explanation
Validation failures appearing only at the final step
Endless loop between customers, CS, and the product team.
The workaround: send a long external form, translate the data internally, manually create the listing on AWS. CS sat with customers for days. PMs attended every call. Developers explained integration requirements live. The product team kept teaching CS what to do.
What couldn't change
AWS rules. Schemas, validations, and compliance requirements were fixed.
The cost of errors. Rejections didn't just frustrate users. They blocked revenue.
Multi-role reality. No single user ever had everything needed to complete a listing alone.
Multi-cloud future. Azure and GCP support was coming. Nothing could be AWS-specific in logic or language.
AWS Marketplace listings took 2–3 months, three internal teams, and revenue lost every day in between.
This did not scale.
This is how it looked at the end.
Who Uses It
There was no single primary persona. Each stakeholder had a specific job and none of them acted alone.
Persona 1:
Cloud Partner Manager
Cloud Ops
Who they are
Owns the end-to-end process of getting cloud partners live on marketplaces. They coordinate partner onboarding, create and validate product listings, and manage the full offer lifecycle across AWS, Azure, and GCP. Highly comfortable with cloud consoles, automation tools, and dashboards.
Goals
Successfully onboard partners and get their products live on marketplaces, ensure listings are compliant and optimized for discoverability, and manage offers from creation through fulfillment and renewal.
Persona 2:
DevOps / Compliance
Who they are
Ensures cloud marketplace listings meet internal security policies and regulatory requirements. Reviews IAM roles, validates CloudFormation deployments, and flags compliance blockers before listings go live. Strong command of cloud infrastructure, DevOps, and security standards.
Goals
Validate IAM and infrastructure setup across cloud listings, ensure compliance with security and legal requirements, and track review and approval status across marketplace onboarding checklists.
Persona 3:
CRM Admin
Who they are
Manages the technical integration between Labra and CRM systems like Salesforce or HubSpot. Handles user provisioning, access control, environment configurations, and data integrity. Comfortable with APIs, authentication methods, and CRM admin tools, and can troubleshoot issues independently or with support.
Goals
Ensure seamless CRM-to-Labra data sync for account and opportunity data, manage user permissions and access control, and minimize friction for sales teams relying on the integration.
Persona 4:
Marketing & Growth Ops
Who they are
Owns the content and performance of marketplace listings, writing product copy, aligning messaging with brand and GTM strategy, and monitoring listing engagement. Understands marketing flows well but is not deeply versed in cloud infrastructure or marketplace mechanics. Needs guided workflows.
Goals
Publish and maintain listing content accurately, ensure brand consistency across partner channels, drive lead generation through optimized listings, and monitor visibility and engagement of published assets.
The Solution
Two years of this loop. 100 plus screens.
The flow wasn't designed once. It evolved as AWS rules changed, new listing types were added, and customers revealed new friction points. Research was continuous because customers were continuously onboarding. Every new user surfaced patterns, rejections, and jargon gaps that fed directly back into design.
The design system
I built Labra's first design system as the company's first designer. Every screen in this case study sits on top of it.
1. Reducing cognitive load
Reduced cognitive load as much possible.
01.
Progressive disclosure. Show only what's needed at each step. Delay AWS complexity until it's required.
02.
Guided step-based workflow. Completed, active, and pending are visually distinct, users always know where they are and what's next.
03.
Contextual help in the sidebar. Video tile sits alongside the form. Available all the time.
2. Preventing errors before they happen
Error prevention > error handling.
01.
Prerequisites are Step 01, not buried in docs. Users confirm readiness before they begin.
02.
Clarity of who in the org needs to do what.
03.
Error prevention > error handling. Inline validations, strict checks, and clear error states, no surprise failures at the end.
04.
Autosave & draft support. Users could safely pause and resume without fear of losing progress.
3. Teaching inside the product
Users no longer needed external AWS docs to proceed. CS involvement dropped sharply.
01.
Inline education & contextual help. AWS jargon was explained where it appeared, using tooltips, inline descriptions, and help sections (videos, demos, documentation).
02.
"Note:" callouts whenever needed to prevent the common mistake.
03.
Scoped Help & FAQs. Anchored at the section header, not the page header. So help is tied to the specific decision being made.
01.
Contextual video where it's relevant, for users who want a walkthrough instead of reading.
4. One framework, many contexts
Support multiple listing types with one framework. Modular, reusable steps and components instead of bespoke flows for Onboarding, Listings, Co-sell, and CRM.
01.
Same stepper, same autosave, same help pattern. Users who learned onboarding already know how to use co-sell. One mental model, many modules.
02.
Role icons per step. Tell users who completes what before they start.
03.
Step-level prerequisites mirror onboarding.
01.
Same framework applied to CRM integration.
01.
Progress bars per module. Users always know where they left off across Marketplace, Co-sell, and Marketing.
02.
Multi-cloud badges on each module. AWS, GCP, Microsoft.
5. AI embedded in the flow
Generative AI integration wherever possible to make life easier.
"Write with AI" inline on every description field.
Drafts generated from product details already filled in. The system uses context the user has already provided rather than asking them to start over in a prompt.
Impact
A process that used to take 2-3 months became completable in under a week, mostly self-serve, without hand-holding.
Before
2–3 months to get listed, with heavy support involvement
Listing rejections and the loop used to start again
Users used to drop at onboarding
CS sat with customers for days or weeks per listing
PMs attended every customer call as mandatory participants
Developers pulled in to explain random things in real time
Product team constantly teaching CS what to do
After
Under a week in ideal conditions, mostly self-serve
Almost zero listing rejections ( Prerequisites and validations)
Higher onboarding completion rates
CS involvement: a few combined hours per week total
PMs rarely needed on customer calls
Product answered questions before they were asked
CS handled questions independently
AI opportunities
Near-term:
AI-Powered Readiness Assessment: Instead of a static prerequisites checklist, an AI layer scans what a customer has already configured and generates a personalised readiness report: what's missing, in what order to fix it, how long each step takes.
Cross-Marketplace Adaptation: AI that takes a completed AWS listing and automatically adapts it for Azure and GCP, different schemas, terminology, and compliance rules, reducing a weeks-long process to review-and-confirm.
Long-term:
Conversational Listing Creation: A user describes their product in natural language and AI drafts the full listing structure, selects the appropriate type, and surfaces missing information in one pass. The form becomes a dialogue.
Automated Compliance Monitoring: AI that monitors policy changes across AWS, Azure, and GCP and proactively flags which active listings are affected, turning compliance from a reactive scramble into a continuous managed process.
Multi-Stakeholder Coordination Agent: An AI agent that tracks what information is missing, knows who owns it, and nudges the right person at the right time. Directly addresses the coordination bottleneck that was one of the core constraints of this project.
Reflection
Too many people were involved. Too many people were working on daily listings and we had to incorporate everyone's feedback, which created a lot of chaos. We needed a better, structured way to coordinate with everyone — not taking on too much feedback, but also not letting things fall through the cracks.
I would standardise user education better if I were to recreate the entire flow. Right now, the flow has inline descriptions, tooltips, videos, a right-side drawer with additional help documents, and external Labra docs on top of everything. That's a lot for users. I would standardise on one or two methods and use those consistently throughout.
More Work
Pruthviraj Chandak · Lead Product Designer, India