Overview
Autodesk sells 100+ products across every region, currency, and customer type, generating over 100k price variants. When I joined, pricing logic lived in disconnected spreadsheets. Promotion managers looked up SKU codes manually and had no way to know if their data was current. Over 3 years as the sole designer, I worked with PMs, business analysts, and business architects to build a pricing platform that became the source of truth for every Autodesk transaction, powering self-serve purchases, internal sales teams, partners, and resellers. I designed a set of reusable patterns (multi-step creation, contextual filtering, inline validation, status tracking) that started with renewal discounts and proved flexible enough to absorb promotions, volume discounts, and value-based pricing from acquired construction products. Promotion setup time dropped by at least half and an entire class of configuration errors was eliminated.
Problem
Autodesk sells 100+ products across every market, currency, and business model. A single product like AutoCAD doesn't have one price. It has hundreds of variants depending on term length, region, customer type, and sales channel. When I joined, pricing logic lived in spreadsheets that pricing managers maintained independently. Promotions were configured by looking up SKU codes in Excel files that might be outdated, then entering them into a long form with no validation. If an offer wasn't available in a specific region, the system wouldn't stop you. Promotions went live with the wrong offers included, or the right ones missing, because someone believed they'd added the correct SKU from a spreadsheet that was already out of date.
The problem wasn't just speed. It was that the workflow required people to hold the complexity in their heads: which offers are valid for which regions, which SKUs map to which products, whether the catalog they're referencing is current. One promotion manager estimated setup took at least twice as long as it should, "depending on how much you can concentrate or knowing if you have the correct latest pricing catalog."
Solution
I inherited a system where each new pricing feature got its own UI. Long forms, inconsistent layouts, no shared patterns. I worked closely with PMs, business analysts, and business architects who understood the underlying logic of these pricing models, alongside a principal engineer who advocated for the same kind of simplicity. Together we introduced a multi-step creation flow that became the foundation for everything we built over the next 3 years. The PMs and business architects saw the value immediately: reusing a proven pattern meant less implementation complexity every time we added a new pricing model. That speed mattered. The pricing platform feeds every downstream system where sales happen, from the eStore to enterprise sales tools. Nothing goes live until pricing is configured, so the platform couldn't be a bottleneck.
Home page showing tiles of the different pricing configurations and rules that can be created
Renewal discounts
The first test was renewal discounts. Instead of a single long form, I broke creation into discrete steps: define the discount parameters, select eligible offerings, set regional availability, review and activate. Each step validates before you move forward, so errors surface early rather than after a promotion is live. I added status indicators showing which steps are complete, which are in progress, and which are blocked. This meant one person could set up the basics and hand it off to someone else to finish, which matched how these teams actually worked.
Status indicators show which steps are complete and which still need attention
A completed renewal discount with all steps validated, ready to activate
Promotions
When promotions came next, the pattern was already proven. The difference was complexity: promotions needed market-specific controls (available in Japan but not the US), BOGO logic, and date ranges. The multi-step framework absorbed all of this without requiring a new mental model.
The biggest design decision was integrating offering data directly into the promotion flow. In the old system, promotion managers looked up SKU codes in external spreadsheets and entered them manually. If a spreadsheet was outdated or a SKU didn't apply to a given region, nothing stopped them. Promotions went live broken. I replaced that with contextual filtering: the system only shows offers that are actually valid for the promotion's configuration. If you've set it to Japan, you only see Japan-eligible offers. The entire category of "wrong SKU" errors disappeared.
I also pulled familiar elements from the legacy pricing tools these teams already used into the step design. Adoption mattered more than novelty. If the interface felt recognizable to a pricing manager who'd spent years in those systems, they'd trust it faster.
Value-based pricing
Autodesk's construction products already used a value-based pricing model, charging a percentage of a project's value with tiered rates based on project size. But that system lived in isolation, disconnected from the rest of Autodesk's product catalog. The goal wasn't to build value-based pricing from scratch. It was to bring it into the same platform so that multiple business models could be managed from one place. A construction product could be sold as a value-based tier or as a simple yearly subscription, configured side by side with legacy products like AutoCAD.
One step defines the tiers (percentage rates at different project value thresholds). Another assigns offerings to those tiers, so multiple products can share the same tier structure. The pattern held. A pricing manager creating a value-based tier used the same interaction model as one creating a promotion or a renewal discount. Same status indicators, same step-by-step validation, same ability to hand off incomplete work.
The pricing platform became the source of truth that powered both the eStore for self-serve purchases and enterprise sales tools for quotes, across every business model Autodesk sells.
Pricing schedules define tier rates for value-based products, using the same multi-step pattern
The same incomplete-to-complete progression, proving the pattern held across fundamentally different business logic
Outcome
Promotion setup time dropped from an estimated 16+ minutes to an 8-minute average, with the promotion manager noting it could be more depending on how complex the old spreadsheet lookups were. The contextual filtering eliminated an entire class of configuration errors: promotions going live with wrong or missing offers because someone entered an outdated SKU. The platform now manages 100k+ price variants across 100+ products and serves as the pricing source of truth for every Autodesk transaction, from self-serve purchases to internal sales teams to partner and reseller channels.
The patterns outlasted any single feature. Renewal discounts, promotions, volume discounts, and value-based tiers all use the same creation framework. When new business models or acquisitions need pricing support, the system absorbs them without requiring a new interface.
What worked, what I'd change
Building the multi-step pattern incrementally was the right call. Starting with renewal discounts (lower complexity, clear validation needs) gave us a proven foundation before we hit the harder problems. By the time value-based pricing arrived, the pattern had been tested across enough use cases that adoption was straightforward for both the engineering team implementing it and the pricing managers using it.
Studying the legacy tools these teams already relied on paid off more than I expected. Pricing managers didn't need a better-looking interface. They needed one that matched their mental model but removed the error-prone parts. Familiarity drove trust, and trust drove adoption.
I'd invest more in the audit and change history experience earlier. With 100k+ price variants and multiple people configuring promotions and discounts, knowing who changed what and when became critical. We built it, but it came later than it should have. For a system that's the single source of truth for pricing, auditability should have been a first-class feature from the start.