Wistia
Wistia is a video platform for marketing teams. I led product design for its Growth pillar through a plan consolidation and a storefront simplification, shipped production code when speed mattered, and learned where growth design runs out of math.
- Role
- Product design lead, Growth
- Tenure
- 2025 to 2026
- Team
- A senior designer and me
- Surface
- Plans, storefront, subscriptions, onboarding
What I walked into
Wistia sold five plans, two webinar tiers, and an automation add-on, then asked visitors to sort it all out on one pricing page.
The role was scoped for execution. The business owned the pricing calls: which plans survived, what they cost, how accounts moved. Growth design owned whether a person could understand those calls in the time it takes to scan a pricing page, and whether the workflows underneath held once they bought.
The trial storefront offered four ways to start. In the test window we later ran against it, two of those four drew a single trial each. The menu was doing the customer's thinking for them, and doing it badly.
I owned the Growth surface with a senior designer alongside me. This case study stays on the pricing page, because that is where the lessons landed hardest.
Plans
Platform architecture. Five plans collapsed to Free, Business, and Enterprise.
Storefront
The pricing page and trial offers. Webinars and the Automation Suite surfaced as first-class add-ons.
Subscriptions
Self-serve add-ons and metered resources, gated on payment method and contract.
Onboarding
Contextual, progressive activation that teaches the product by using it.
The market moved
Two forces outside the building shaped most of the decisions inside it.
A tighter economy
Marketing budgets tightened, and every tool in the stack had to justify its line item. A trial had to prove value fast, because the annual contract behind it got harder to sign.
AI video everywhere
AI-powered hosting and editing tools multiplied online, many of them cheap or free. Hosting a video stopped being a differentiator. Turning a view into a lead still was.
[That pressure set the storefront's priorities. Webinars and the Automation Suite carried the argument hosting no longer could, so the page had to surface them without burying the plan underneath.]
Growth design inherited the pressure as a speed problem. The market changed faster than a quarterly roadmap could answer it, so the team that could test and ship fastest had the best chance of keeping up.
Three plans, many paths
The business reduced five plans to three: Free, Business, Enterprise. Go-to-market owned remapping the accounts. The combinations underneath stayed exactly as complicated as before.
Every legacy and custom account carried its own storage, seat, and webinar levels. Each one had to land on a new plan, read correctly on the pricing page, and stay self-serviceable after the move. My charge was the storefront and the self-serve layer for all of it.
Step through the layers to watch three plans become fourteen governed paths.
Three plans on the surface
Free, Business, Enterprise. The tidy version, and the one the pricing page leads with.
That was the storefront. Underneath it, every existing account still had to move.
Retired plans, plus older offerings customers had been grandfathered into, each running several variants of its own. Migration forced one call per account. Customers either kept their price and got more plan, or moved to the plan their actual usage justified, with add-ons available whenever they needed more. Accounts that ran well past the base packages, like companies with large seat counts, went into a did-not-fit bucket and kept their plans at the higher price points.
Go-to-market decided which road each account took. My charge was making every landing self-serviceable, including the way back up. Trace any offering through the map.
One decision per account
Every old offering ran several variants of its own, drawn here as the stack behind each card. At migration each account took one of three roads: more plan at the same price, a plan sized to its usage, or an exception that kept its existing plan.
Hover, tap, or tab to any card to trace it
For illustration purposes — the old plans and tiers required risk-assessment decisions prior to a forced migration.
The plans collapsed to three. The permutations didn’t.
The storefront test
The legacy trial storefront spread visitors across four offers. We tested it against two.
Business on its own, and Business with Webinars. Collapsing the menu nearly doubled trial starts and moved most of the demand to the higher-value offer. Fewer choices, more starts, better mix.
The result was real enough to act on and too thin to call. That gap became the lesson of the whole engagement, and it gets its own section further down.
~2× more visitors started a trial under the simplified offer.
Demand moved to the higher-value offer once the noise came out.
Directional read · single test window, small sample.
Shipping the code
On Growth, a test idea moves only as fast as its path to production. I shortened the path submitting my own PRs.
A quick example was this Automation Suite banner that sells a $250-a-month add-on to the Business plan: video engagement as a signal for lead scoring, campaign triggers, and revenue attribution. Six integration marks answer the first question a marketing ops buyer asks, which is whether it works with their stack, each leading to a PDP for that integration.
I tuned the interaction in the browser, where it would actually live. The marks respond to the pointer, the trial button presses like a physical control, and the plan requirement sits right under the button, where a skeptical buyer looks before clicking.
One artifact
The spec and the build were the same thing. Nothing got lost between the mockup and production, because the mockup was production.
Cheaper variants
A new variant cost a design decision instead of a slot in someone else's sprint. On a page with limited traffic, every week a test waits to launch is a week of learning gone.
Engineering stayed on the hard parts
Platform engineers kept their focus on billing, entitlements, and migration logic. The storefront moved without borrowing their time.
What it moved
Simpler plans, a simpler storefront, and subscriptions customers could manage themselves.
Simplifying the offer and opening self-service subscription management lifted MRR ahead of the company's larger plays.
95 to 195 when the storefront went from four trial offers to two.
Demand moved toward the higher-value plan once the noise came out.
The storefront, the self-serve guardrails, the code behind the banner, and the test design. The business made the pricing calls and go-to-market moved the accounts. The MRR lift belongs to the whole offering change, and I left before the trial-offer read had full validation.
Where the math ran out
The pricing page never drew enough traffic to tell a winner from a loser with statistical significance, at any speed we could live with.
Trial starts were the loud signal. The outcomes the business cared about, paid conversion and add-on revenue, sat further down the funnel, where the counts got small fast. Every extra variant split those counts again.
The arithmetic is unforgiving. Detecting a modest lift on a low baseline takes tens of thousands of visitors per variant. Change the inputs and watch how quickly a clean read slides past the end of a quarter.
To catch a move from 5% to 6.0% with 95% confidence and 80% power.
At 2,000 visitors per variant each week. Split the page four ways and the traffic per variant drops with it.
Readable inside a quarter, if nothing else ships to the page in the meantime.
Illustrative inputs. Standard two-proportion power math, 95% confidence, 80% power. Wistia's actual traffic stays private.
We ran tests anyway, read them directionally, and made calls. That was the right instinct for speed and the wrong posture for rigor. A directional read on a small sample tells you which way to lean. It can't tell you how hard.
The signal problem ran deeper than traffic. We had monitoring benchmarks for the accounts most likely to retain, but no meaningful read on which features drove a Free account to purchase. Activity data measured hosting, and hosting barely moved while the company tried to evolve past it. The metric stayed flat because it described the old product.
Low traffic turns test design into the design problem.
What I'd do differently
Push for more rigor in measurement, earlier, and stop treating the fixed A/B split as the only tool in the box.
Shipping my own code made experiments cheap to launch. It did nothing for how much each one could teach us. Three changes would have closed that gap.
Agree on the math first
Before anyone builds a variant, set the smallest effect worth detecting, the runtime the traffic can actually support, and the guardrail metrics. If the runtime lands past the decision date, redesign the test.
Model propensity on usage
Score accounts on what they do in the product: which features they touch, how often, and what they touch before they upgrade. Stratify assignment by that score and read results against expected behavior, so each visitor carries more information. The model should track the product the company is becoming, so webinars and automation usage count alongside hosting.
Allocate with bandits
For calls where speed matters more than certainty, like offer order or banner variants, let a multi-armed bandit shift traffic toward the leader while the test runs. Fewer visitors land on the losing variant.
Simulated. 200 visitors a day, two variants converting at 4.0% and 5.0%. Run it again to see the variance. Now and then it backs the wrong variant for a stretch, which is the certainty it trades away.
A bandit trades some certainty for a cheaper path to a decision. Traffic drifts toward the leader while the test runs, so a low-traffic page pays less for every lesson. Pair it with propensity scores and a measurement plan agreed before the build, and a small page can still run a disciplined program.
Growth design is a measurement discipline with a visual surface. On the next growth engagement, the test plan ships with the design brief. I size every experiment against real traffic before anyone opens a design file, and I pick the allocation method to fit the decision it serves.
Wistia
Wistia is a video platform for marketing teams. I led product design for its Growth pillar through a plan consolidation and a storefront simplification, shipped production code when speed mattered, and learned where growth design runs out of math.
- Role
- Product design lead, Growth
- Tenure
- 2025 to 2026
- Team
- A senior designer and me
- Surface
- Plans, storefront, subscriptions, onboarding
What I walked into
Wistia sold five plans, two webinar tiers, and an automation add-on, then asked visitors to sort it all out on one pricing page.
The role was scoped for execution. The business owned the pricing calls: which plans survived, what they cost, how accounts moved. Growth design owned whether a person could understand those calls in the time it takes to scan a pricing page, and whether the workflows underneath held once they bought.
The trial storefront offered four ways to start. In the test window we later ran against it, two of those four drew a single trial each. The menu was doing the customer's thinking for them, and doing it badly.
I owned the Growth surface with a senior designer alongside me. This case study stays on the pricing page, because that is where the lessons landed hardest.
Plans
Platform architecture. Five plans collapsed to Free, Business, and Enterprise.
Storefront
The pricing page and trial offers. Webinars and the Automation Suite surfaced as first-class add-ons.
Subscriptions
Self-serve add-ons and metered resources, gated on payment method and contract.
Onboarding
Contextual, progressive activation that teaches the product by using it.
The market moved
Two forces outside the building shaped most of the decisions inside it.
A tighter economy
Marketing budgets tightened, and every tool in the stack had to justify its line item. A trial had to prove value fast, because the annual contract behind it got harder to sign.
AI video everywhere
AI-powered hosting and editing tools multiplied online, many of them cheap or free. Hosting a video stopped being a differentiator. Turning a view into a lead still was.
[That pressure set the storefront's priorities. Webinars and the Automation Suite carried the argument hosting no longer could, so the page had to surface them without burying the plan underneath.]
Growth design inherited the pressure as a speed problem. The market changed faster than a quarterly roadmap could answer it, so the team that could test and ship fastest had the best chance of keeping up.
Three plans, many paths
The business reduced five plans to three: Free, Business, Enterprise. Go-to-market owned remapping the accounts. The combinations underneath stayed exactly as complicated as before.
Every legacy and custom account carried its own storage, seat, and webinar levels. Each one had to land on a new plan, read correctly on the pricing page, and stay self-serviceable after the move. My charge was the storefront and the self-serve layer for all of it.
Step through the layers to watch three plans become fourteen governed paths.
Three plans on the surface
Free, Business, Enterprise. The tidy version, and the one the pricing page leads with.
That was the storefront. Underneath it, every existing account still had to move.
Retired plans, plus older offerings customers had been grandfathered into, each running several variants of its own. Migration forced one call per account. Customers either kept their price and got more plan, or moved to the plan their actual usage justified, with add-ons available whenever they needed more. Accounts that ran well past the base packages, like companies with large seat counts, went into a did-not-fit bucket and kept their plans at the higher price points.
Go-to-market decided which road each account took. My charge was making every landing self-serviceable, including the way back up. Trace any offering through the map.
One decision per account
Every old offering ran several variants of its own, drawn here as the stack behind each card. At migration each account took one of three roads: more plan at the same price, a plan sized to its usage, or an exception that kept its existing plan.
Hover, tap, or tab to any card to trace it
For illustration purposes — the old plans and tiers required risk-assessment decisions prior to a forced migration.
The plans collapsed to three. The permutations didn’t.
The storefront test
The legacy trial storefront spread visitors across four offers. We tested it against two.
Business on its own, and Business with Webinars. Collapsing the menu nearly doubled trial starts and moved most of the demand to the higher-value offer. Fewer choices, more starts, better mix.
The result was real enough to act on and too thin to call. That gap became the lesson of the whole engagement, and it gets its own section further down.
~2× more visitors started a trial under the simplified offer.
Demand moved to the higher-value offer once the noise came out.
Directional read · single test window, small sample.
Shipping the code
On Growth, a test idea moves only as fast as its path to production. I shortened the path submitting my own PRs.
A quick example was this Automation Suite banner that sells a $250-a-month add-on to the Business plan: video engagement as a signal for lead scoring, campaign triggers, and revenue attribution. Six integration marks answer the first question a marketing ops buyer asks, which is whether it works with their stack, each leading to a PDP for that integration.
I tuned the interaction in the browser, where it would actually live. The marks respond to the pointer, the trial button presses like a physical control, and the plan requirement sits right under the button, where a skeptical buyer looks before clicking.
One artifact
The spec and the build were the same thing. Nothing got lost between the mockup and production, because the mockup was production.
Cheaper variants
A new variant cost a design decision instead of a slot in someone else's sprint. On a page with limited traffic, every week a test waits to launch is a week of learning gone.
Engineering stayed on the hard parts
Platform engineers kept their focus on billing, entitlements, and migration logic. The storefront moved without borrowing their time.
What it moved
Simpler plans, a simpler storefront, and subscriptions customers could manage themselves.
Simplifying the offer and opening self-service subscription management lifted MRR ahead of the company's larger plays.
95 to 195 when the storefront went from four trial offers to two.
Demand moved toward the higher-value plan once the noise came out.
The storefront, the self-serve guardrails, the code behind the banner, and the test design. The business made the pricing calls and go-to-market moved the accounts. The MRR lift belongs to the whole offering change, and I left before the trial-offer read had full validation.
Where the math ran out
The pricing page never drew enough traffic to tell a winner from a loser with statistical significance, at any speed we could live with.
Trial starts were the loud signal. The outcomes the business cared about, paid conversion and add-on revenue, sat further down the funnel, where the counts got small fast. Every extra variant split those counts again.
The arithmetic is unforgiving. Detecting a modest lift on a low baseline takes tens of thousands of visitors per variant. Change the inputs and watch how quickly a clean read slides past the end of a quarter.
To catch a move from 5% to 6.0% with 95% confidence and 80% power.
At 2,000 visitors per variant each week. Split the page four ways and the traffic per variant drops with it.
Readable inside a quarter, if nothing else ships to the page in the meantime.
Illustrative inputs. Standard two-proportion power math, 95% confidence, 80% power. Wistia's actual traffic stays private.
We ran tests anyway, read them directionally, and made calls. That was the right instinct for speed and the wrong posture for rigor. A directional read on a small sample tells you which way to lean. It can't tell you how hard.
The signal problem ran deeper than traffic. We had monitoring benchmarks for the accounts most likely to retain, but no meaningful read on which features drove a Free account to purchase. Activity data measured hosting, and hosting barely moved while the company tried to evolve past it. The metric stayed flat because it described the old product.
Low traffic turns test design into the design problem.
What I'd do differently
Push for more rigor in measurement, earlier, and stop treating the fixed A/B split as the only tool in the box.
Shipping my own code made experiments cheap to launch. It did nothing for how much each one could teach us. Three changes would have closed that gap.
Agree on the math first
Before anyone builds a variant, set the smallest effect worth detecting, the runtime the traffic can actually support, and the guardrail metrics. If the runtime lands past the decision date, redesign the test.
Model propensity on usage
Score accounts on what they do in the product: which features they touch, how often, and what they touch before they upgrade. Stratify assignment by that score and read results against expected behavior, so each visitor carries more information. The model should track the product the company is becoming, so webinars and automation usage count alongside hosting.
Allocate with bandits
For calls where speed matters more than certainty, like offer order or banner variants, let a multi-armed bandit shift traffic toward the leader while the test runs. Fewer visitors land on the losing variant.
Simulated. 200 visitors a day, two variants converting at 4.0% and 5.0%. Run it again to see the variance. Now and then it backs the wrong variant for a stretch, which is the certainty it trades away.
A bandit trades some certainty for a cheaper path to a decision. Traffic drifts toward the leader while the test runs, so a low-traffic page pays less for every lesson. Pair it with propensity scores and a measurement plan agreed before the build, and a small page can still run a disciplined program.
Growth design is a measurement discipline with a visual surface. On the next growth engagement, the test plan ships with the design brief. I size every experiment against real traffic before anyone opens a design file, and I pick the allocation method to fit the decision it serves.