Laura Schaffer
VP of Growth at Amplitude, previously led growth and product at Twilio, Bandwidth and Rapid
Where to hear and read about Laura Schaffer1 episode or test
Laura Schaffer is VP of Growth at Amplitude, after more than seven years leading growth at Twilio and a stint as VP of product and growth at Rapid. The lesson most worth taking from her is that most growth ideas fail, so the edge is validating cheaply and quickly while designing for how users feel at each step.
Failure doesn't have to be a wall. It can be a compass.
Career frameworks, A/B testing, onboarding tips, selling to engineers | Laura Schaffer (Amplitude)
Laura Schaffer: the story and the lessons
1Laura Schaffer's path from Bandwidth sales to Amplitude
Schaffer turned repeated sales answers into a self-serve product at Bandwidth. At Bandwidth, then about 50 people, she was in sales and kept giving customers the same answers, which was slow for them and costly in commissions. She proposed a fix and built a self-serve flow called e-commerce manager in 2010.
She expected her GM to say the company had already thought it through. He said "tell me more" and had her build it.
She joined Twilio in late 2014 in product marketing, writing messaging lines. She spent over seven years there, ending as head of growth and PM lead of the growth and experimentation platforms.
Her customer conversations contradicted leadership's belief that Twilio was easy to start with, and that gap shaped her next move.
Schaffer moved from Twilio to Rapid, then to Amplitude, succeeding Elena Verna. She was VP of product and growth at Rapid before taking over growth at Amplitude. She recorded the interview in her first week, on day two and a half of the job.
Elena Verna sent her to the show. Schaffer joked she was at the very bottom of Amplitude's tenure list after a long stretch at Twilio.
2How Schaffer builds a career by filling gaps
She says waiting to be promoted caps your growth. Working hard inside your role limits you to what your manager can do for you and your role's trajectory. If your manager leaves, you restart with someone new.
Her alternative is to spot a gap and fill it yourself. Keeping win spreadsheets and self-advocacy is "all good stuff", but your view of yourself and theirs can differ.
Schaffer started a voice of the customer report with no permission. Within months of joining Twilio, people asked to be on its list. Senior leaders requested a quarterly session, and CEO Jeff Lawson attended.
The session became a forum where others sent insights for her to compile. She began without any formal proposal.
She won a growth team by lining up allies before the pitch. In 2015 planning she pitched "we think it's easy, it is not". Andre Crow, the seventh Twilio hire, who led the website and created the Twilio brand, backed her.
The meeting before the meeting was already done. The pitch led to Twilio's growth engineering and growth product team.
Schaffer calls customer insight the most accessible route up in any role. Executives lose touch with customers as a company grows, so insights tied to North Star metrics are the strongest. Being the person who knows customers gets you asked for feedback, hiring and cross-team projects.
She says customer-facing people who want into product already know customer pain. She also advises sharing other strengths, such as posting tips in a general Slack channel.
She says taking initiative helps your manager rather than working against them. These moves helped her manager promote her, because calibration rooms go easier when others have seen you in a positive light.
It also takes back momentum instead of relying on one person.
Schaffer interviews by asking about a recent ship the candidate did not pick. Everyone has a big success story, so asking for a best release tells you little. A recent or specified ship cannot be cherry-picked.
The candidate then explains their approach, which is what predicts whether they will succeed.
3What Schaffer learned about user psychology and friction at Twilio
Schaffer ran a Friday-evening signup test expecting conversion to drop. Twilio's signup asked only for username, email and password, on the belief that developers want nothing in their way. Around 7 p.m. on a Friday she and Andre Crow added questions for a small group.
She had a framework ready to defend the data she expected. She says engineering approval is the right way to change production, and that skipping it here was a call to use with caution.
Four signup questions lifted Twilio conversion by about 5 percent. The questions covered coding language, use case, product of interest and whether the user was a developer. There was no personalization, only the questions.
Conversion rose because they comforted people. Picking JavaScript from a list told users their language was supported, and picking a use case told them they were in the right place.
She says good friction eases a worry the user already has. New users expect friction and are "looking for the bogeyman". Every front door makes them ask whether they are in the right place and whether they can figure it out.
Her line: "bad friction is bad and good friction is good".
The answers also gave product and docs teams data they lacked. One question separated developers from non-coders. Language data helped the docs team see trends before year-end reports, and product choice such as SMS or voice shaped each person's onboarding.
Before this, Twilio did not know who signed up or what they wanted to build, which hurt analysis and prioritization.
A tidy step-by-step onboarding converted only modestly at Twilio. It replaced a "choose your own adventure" with prescriptive steps, meant to make Twilio feel less complex. Interviews and mocks showed nothing obviously wrong.
Developers found APIs and docs familiar but phone numbers and telecom foreign. In self-serve, the user faces that scary step alone, with no teacher beside them.
Schaffer hid the scary phone-number step inside a code-first docs page. Users first saw code in their own language, with the phone number embedded rather than leading. The MVP gave them no easy return button to the console.
It validated, and once rebuilt into the real flow it converted even better. She likens it to hiding a pill in a hot dog so the bogeyman cannot "party".
4Schaffer's rules for running growth experiments
She treats a failed experiment as the normal case. Roughly 80% of tested ideas fail at companies like Netflix and Microsoft, and some report 90%. A win needs the right problem, person, moment, solution and framing, and one miss sinks it.
She says a high failure rate says nothing about how smart you are, and to build it into strategy rather than fight it.
Schaffer validates with painted doors and mocks before any A/B test. A/B tests are among the most expensive validation methods because they need design, engineering and a PM. Only vetted ideas should reach one.
Failing faster with cheaper methods lowers the failure rate at the expensive stage. She prefers improving validation speed to trying to beat everyone's hit rate.
She ships early and wants the first version to feel embarrassing. The longer you build before showing anyone, the likelier you ship a wrong idea. Kicking users out of the onboarding portal, after paying to get them there, sounded nuts but worked.
Her rule: "if you were not embarrassed you've gone too far". It also helps teams celebrate unpolished work.
Schaffer accepts confidence below 95 percent to run more experiments. She ran lab experiments in college, where false positives could distort education research. Growth work carries no such risk, and a looser bar can double the experiments run in a year.
Ten tests at an 80% fail rate yields about two wins. She says it is "a huge risk in and of itself to not ship as much as you possibly could in a year".
She requires the hypothesis and plan before the test runs. A common failure is running the test and then making the data fit the hypothesis, or having no hypothesis at all.
The rule matters more with a looser bar. She says to "have this game plan set before you run something".
She pairs thinner numbers with qualitative feedback. For the hot dog test she would read feedback from both groups. The new flow should say it felt easy, and the old one should say they got stuck on the phone number.
At Rapid, linking Amplitude, Segment and Hotjar exposed an odd usage pattern, and screencasts of that event produced hypotheses without contacting customers.
Schaffer asks leaders to judge growth teams on a year of low, medium and high bets. High bets are a few core hypotheses that could be lightning in a bottle or paper mist. Safer bets were partly validated the year before.
Short reporting cycles push teams to massage data and chase vanity metrics. She spent a large part of her time at Twilio and Rapid educating others on this.
5How Schaffer got Quick Deploy to tens of millions in Twilio pipeline
She noticed signup data showed a growing group of non-developers who wanted to build. The count of users calling themselves non-developers kept rising. They were not lost, but they struggled through developer onboarding.
Sales told her that once a buyer got started, spend grew from $1 to $5 to $10,000 to $100,000. The blockers were writing code from scratch and standing up a server.
Her team built Quick Deploy on Code Exchange for no-code first wins. It let anyone deploy an app without writing code, working as a create-your-own-demo experience. Sales got something powerful to hand to non-engineering buyers.
The thinking was that if non-engineers could get it running, their development team definitely could. It came from iterative experiments, not one build, and generated tens of millions of dollars in pipeline.
6Schaffer on selling to developers and adding self-serve
Schaffer says developers must prove a product themselves before they commit. Developers are responsible when a tool fails, so they will not take a sales rep's word. They want a proof of concept before they buy.
A Fang company signed up for Twilio, built a proof of concept and ran in production for months without talking to sales. A giant retailer's engineers used personal emails to dodge outreach.
She says developer companies must treat self-serve like their sales force. Developers will not accept sales stepping in at the proof-of-concept stage, so growth and self-serve teams carry the conversion work.
She adds that skills from other audiences do not carry over, so founders who pivot to developers face a steep climb.
Developers skip the marketing site and go straight to signup. She says almost 2 to 1 developers do not look at the marketing website at all. They act like IKEA buyers who tear open the bags and look for instructions only when stuck.
So signup must be self-explanatory, with context in the flow for the moment they get stuck.
She starts Amplitude's self-serve strategy from customer problems, not the product. Self-serve is not the enterprise offering chopped into pieces with a debated price like $99 or $104. Her hypothesis is that SMB and startup users lack analysts and want reassurance they can get the right metrics and reports.
She frames growth as selling through the product and sales as selling one to one, and says companies need both. Her line: "start with your customers".
Career frameworks, A/B testing, onboarding tips, selling to engineers | Laura Schaffer (Amplitude)
Laura Schaffer explains how to run growth experiments that account for user psychology, why to validate cheaply and iteratively, and how to sell to developers and add self-serve to a sales-led company. Her Twilio experiments included signup questions that lifted conversion by 5 percent and a quick-deploy feature that generated tens of millions of dollars in pipeline.
Schaffer turned repeated sales answers into a self-serve product at Bandwidth. At Bandwidth, then about 50 people, she was in sales and kept giving customers the same answers, which was slow for them and costly in commissions. She proposed a fix and built a self-serve flow called e-commerce manager in 2010.
She expected her GM to say the company had already thought it through. He said "tell me more" and had her build it.
She joined Twilio in late 2014 in product marketing, writing messaging lines. She spent over seven years there, ending as head of growth and PM lead of the growth and experimentation platforms.
Her customer conversations contradicted leadership's belief that Twilio was easy to start with, and that gap shaped her next move.
Schaffer moved from Twilio to Rapid, then to Amplitude, succeeding Elena Verna. She was VP of product and growth at Rapid before taking over growth at Amplitude. She recorded the interview in her first week, on day two and a half of the job.
Elena Verna sent her to the show. Schaffer joked she was at the very bottom of Amplitude's tenure list after a long stretch at Twilio.
She says waiting to be promoted caps your growth. Working hard inside your role limits you to what your manager can do for you and your role's trajectory. If your manager leaves, you restart with someone new.
Her alternative is to spot a gap and fill it yourself. Keeping win spreadsheets and self-advocacy is "all good stuff", but your view of yourself and theirs can differ.
Schaffer started a voice of the customer report with no permission. Within months of joining Twilio, people asked to be on its list. Senior leaders requested a quarterly session, and CEO Jeff Lawson attended.
The session became a forum where others sent insights for her to compile. She began without any formal proposal.
She won a growth team by lining up allies before the pitch. In 2015 planning she pitched "we think it's easy, it is not". Andre Crow, the seventh Twilio hire, who led the website and created the Twilio brand, backed her.
The meeting before the meeting was already done. The pitch led to Twilio's growth engineering and growth product team.
Schaffer calls customer insight the most accessible route up in any role. Executives lose touch with customers as a company grows, so insights tied to North Star metrics are the strongest. Being the person who knows customers gets you asked for feedback, hiring and cross-team projects.
She says customer-facing people who want into product already know customer pain. She also advises sharing other strengths, such as posting tips in a general Slack channel.
She says taking initiative helps your manager rather than working against them. These moves helped her manager promote her, because calibration rooms go easier when others have seen you in a positive light.
It also takes back momentum instead of relying on one person.
Schaffer interviews by asking about a recent ship the candidate did not pick. Everyone has a big success story, so asking for a best release tells you little. A recent or specified ship cannot be cherry-picked.
The candidate then explains their approach, which is what predicts whether they will succeed.
Schaffer ran a Friday-evening signup test expecting conversion to drop. Twilio's signup asked only for username, email and password, on the belief that developers want nothing in their way. Around 7 p.m. on a Friday she and Andre Crow added questions for a small group.
She had a framework ready to defend the data she expected. She says engineering approval is the right way to change production, and that skipping it here was a call to use with caution.
Four signup questions lifted Twilio conversion by about 5 percent. The questions covered coding language, use case, product of interest and whether the user was a developer. There was no personalization, only the questions.
Conversion rose because they comforted people. Picking JavaScript from a list told users their language was supported, and picking a use case told them they were in the right place.
She says good friction eases a worry the user already has. New users expect friction and are "looking for the bogeyman". Every front door makes them ask whether they are in the right place and whether they can figure it out.
Her line: "bad friction is bad and good friction is good".
The answers also gave product and docs teams data they lacked. One question separated developers from non-coders. Language data helped the docs team see trends before year-end reports, and product choice such as SMS or voice shaped each person's onboarding.
Before this, Twilio did not know who signed up or what they wanted to build, which hurt analysis and prioritization.
A tidy step-by-step onboarding converted only modestly at Twilio. It replaced a "choose your own adventure" with prescriptive steps, meant to make Twilio feel less complex. Interviews and mocks showed nothing obviously wrong.
Developers found APIs and docs familiar but phone numbers and telecom foreign. In self-serve, the user faces that scary step alone, with no teacher beside them.
Schaffer hid the scary phone-number step inside a code-first docs page. Users first saw code in their own language, with the phone number embedded rather than leading. The MVP gave them no easy return button to the console.
It validated, and once rebuilt into the real flow it converted even better. She likens it to hiding a pill in a hot dog so the bogeyman cannot "party".
She treats a failed experiment as the normal case. Roughly 80% of tested ideas fail at companies like Netflix and Microsoft, and some report 90%. A win needs the right problem, person, moment, solution and framing, and one miss sinks it.
She says a high failure rate says nothing about how smart you are, and to build it into strategy rather than fight it.
Schaffer validates with painted doors and mocks before any A/B test. A/B tests are among the most expensive validation methods because they need design, engineering and a PM. Only vetted ideas should reach one.
Failing faster with cheaper methods lowers the failure rate at the expensive stage. She prefers improving validation speed to trying to beat everyone's hit rate.
She ships early and wants the first version to feel embarrassing. The longer you build before showing anyone, the likelier you ship a wrong idea. Kicking users out of the onboarding portal, after paying to get them there, sounded nuts but worked.
Her rule: "if you were not embarrassed you've gone too far". It also helps teams celebrate unpolished work.
Schaffer accepts confidence below 95 percent to run more experiments. She ran lab experiments in college, where false positives could distort education research. Growth work carries no such risk, and a looser bar can double the experiments run in a year.
Ten tests at an 80% fail rate yields about two wins. She says it is "a huge risk in and of itself to not ship as much as you possibly could in a year".
She requires the hypothesis and plan before the test runs. A common failure is running the test and then making the data fit the hypothesis, or having no hypothesis at all.
The rule matters more with a looser bar. She says to "have this game plan set before you run something".
She pairs thinner numbers with qualitative feedback. For the hot dog test she would read feedback from both groups. The new flow should say it felt easy, and the old one should say they got stuck on the phone number.
At Rapid, linking Amplitude, Segment and Hotjar exposed an odd usage pattern, and screencasts of that event produced hypotheses without contacting customers.
Schaffer asks leaders to judge growth teams on a year of low, medium and high bets. High bets are a few core hypotheses that could be lightning in a bottle or paper mist. Safer bets were partly validated the year before.
Short reporting cycles push teams to massage data and chase vanity metrics. She spent a large part of her time at Twilio and Rapid educating others on this.
She noticed signup data showed a growing group of non-developers who wanted to build. The count of users calling themselves non-developers kept rising. They were not lost, but they struggled through developer onboarding.
Sales told her that once a buyer got started, spend grew from $1 to $5 to $10,000 to $100,000. The blockers were writing code from scratch and standing up a server.
Her team built Quick Deploy on Code Exchange for no-code first wins. It let anyone deploy an app without writing code, working as a create-your-own-demo experience. Sales got something powerful to hand to non-engineering buyers.
The thinking was that if non-engineers could get it running, their development team definitely could. It came from iterative experiments, not one build, and generated tens of millions of dollars in pipeline.
Schaffer says developers must prove a product themselves before they commit. Developers are responsible when a tool fails, so they will not take a sales rep's word. They want a proof of concept before they buy.
A Fang company signed up for Twilio, built a proof of concept and ran in production for months without talking to sales. A giant retailer's engineers used personal emails to dodge outreach.
She says developer companies must treat self-serve like their sales force. Developers will not accept sales stepping in at the proof-of-concept stage, so growth and self-serve teams carry the conversion work.
She adds that skills from other audiences do not carry over, so founders who pivot to developers face a steep climb.
Developers skip the marketing site and go straight to signup. She says almost 2 to 1 developers do not look at the marketing website at all. They act like IKEA buyers who tear open the bags and look for instructions only when stuck.
So signup must be self-explanatory, with context in the flow for the moment they get stuck.
She starts Amplitude's self-serve strategy from customer problems, not the product. Self-serve is not the enterprise offering chopped into pieces with a debated price like $99 or $104. Her hypothesis is that SMB and startup users lack analysts and want reassurance they can get the right metrics and reports.
She frames growth as selling through the product and sales as selling one to one, and says companies need both. Her line: "start with your customers".