Bad Friction, Good Friction: Laura Schaffer on User Psychology and Growth Experiments

Schaffer begins with the common way people try to grow: work hard in the current role, keep a spreadsheet of wins, and hope your manager and peers notice. She sees this as limiting, because you depend on your manager's ability to advocate for you, on the explicit trajectory of the role, and on a manager who might leave and force you to start over. Her method tries to take some of that power back.

She learned it by accident at Bandwidth, her first real job, where she joined sales when the company had about 50 people. She noticed she kept giving customers the same answers to the same questions, which was bad for customers and inefficient for a company paying commission each time. She suggested putting that information online with self-serve checkout, expecting the general manager to explain what she was missing. He asked her to build it instead, and she moved into a new role.

The lesson, she says, is that executive teams are sharp but their day-to-day does not link them with customers, so as a company grows they lose access to its most valuable insights. Your superpower is pulling those insights in and bringing them to life. No leader is unhappy to hear about customer problems they might not be seeing, particularly when those problems tie to North Star metrics.

Lenny adds that not every idea will be adopted immediately, and that is normal; leaders are still looking for better ideas. Schaffer says becoming the person who "just knows our customers" builds an individual brand that gets you considered for new or cross-team work, and gives you a trajectory beyond your role and your manager.

When Schaffer joined Twilio in product marketing, in late 2014, there was no growth team at all. She made it her policy to do her job well but also to get to know customers broadly, including their pain points beyond her product area. She kept hearing that people struggled to get started with Twilio, which contradicted the executive team's high conviction that Twilio was easy and loved by developers.

Twilio was growing into new markets and adding products and complexity, and was pulling in people who were less motivated, which explained the gap. Because the company was far too big to simply walk the floor, she started writing and sharing a voice-of-the-customer report. It spread by request, turned into a quarterly voice-of-the-customer session for all of product, and eventually the CEO, Jeff Lawson, began attending.

By annual planning for 2015 she had built trust and pitched a growth team backed by her data. She had also lined up Andre Crow, the seventh hire at Twilio, who was close to the CEO and agreed the company needed it. The approval came almost easily, since the meeting before the meeting had already happened.

Asked for more ways to create opportunity, Schaffer says customer insight is the most accessible tool, whether you are in product or customer-facing teams. She also suggests sharing any skill, such as communicating briefly, in a general Slack channel so people see you as a subject-matter expert beyond your role. She stresses this works with your manager, not against them, because it helps managers in calibration meetings when others already know your work. Lenny notes she simply started the report without asking, and she calls that "ungating your knowledge".

Schaffer's first experiment at Twilio challenged a strong belief that developers should be let through the gates with just a username, email and password. She argued this was a costly assumption: without knowing who signed up or what they wanted, the team could not understand performance quantitatively or prioritize well. With no engineering team yet and support from Andre, she added questions to the signup flow at around 7 PM on a Friday and ran it as a small test, asking for forgiveness rather than permission.

She expected the change to hurt numbers and had started drafting a framework to argue for the data. Instead conversion improved by about 5%, with no personalization at all. The four dropdowns asked what language you code in, with an option for not being a developer, which product you want to use, and your use case, and they also fed documentation, onboarding and product decisions.

Talking to a few customers explained why. Signing up for something new is scary and people expect difficulty, "almost like looking for the bogeyman". Questions like "what language do you code in?" reassured them that they were in the right place and that their language and use case were supported. Schaffer sums up the lesson as "bad friction is bad, and good friction is good".

Lenny jokes about her shipping an experiment straight to production as the new person, and Schaffer says to use such moves with caution, since production changes normally need engineering approval. Asked what makes friction good, she says it eases the worry that people can't figure the product out. She encourages every company to include such questions early in onboarding, both to segment users and to boost their confidence.

Schaffer says the signup finding carries over to any front door: users are asking whether they are in the right place and whether they are capable. A strategy built only around the market's problem and what the product can do will miss this third factor, the mentality of the person at each stage of the journey. If you ignore it, things fail and you are left confused as to why.

Her second example came later in onboarding. Twilio replaced a choose-your-own-adventure experience with a prescriptive five-step flow, and conversion improved only modestly. Interviews showed nothing obvious, except that step one was getting a phone number, and telecom was exactly the unfamiliar thing that could trip up developers who were comfortable with APIs, code samples and documentation. In one-on-one teaching, a person sits beside you and reassures you; in self-serve there is nobody to do that.

To test the idea, the team built an MVP that kicked users out of the portal and into a docs page where the first thing they saw was code in their own language. The phone number step was tucked in later, which Schaffer likens to hiding a pill in a hot dog. Even though it sent users away from the console with no easy return, it converted better, and the team then built the approach properly into onboarding. Her advice is that if something very logical isn't converting, you may be fighting the user's psyche.

Lenny asks whether to redesign a whole flow or iterate piece by piece. Schaffer says iteration is always better, because roughly 80% of the time our hypotheses turn out to be wrong, citing an article about companies such as Netflix and Microsoft where 80% or more of ideas fail. The longer you build in isolation, the more likely you ship the wrong 80%.

She frames failure as a compass instead of a wall, which works only if you get things in front of customers early. She tells her teams that if it isn't embarrassing, you have gone too far. Kicking users out of onboarding was embarrassing, but if it hadn't validated, it would have been a cheap and valuable lesson. Lenny says his experience is that full redesigns tend to launch negative, even when designers push for a fresh start.

She argues the 80% figure makes sense given how much must line up: you must understand the problem, the customer, the timing, the right solution and how it is communicated. Any one being off sinks the result. Her advice is to embrace this as a logic of the work, not a verdict on how smart the team is, and make it part of your strategy.

Schaffer says there is little you can do to improve the raw hit rate of untested ideas, but you can validate them much faster. A/B testing is one of the most expensive methods, needing design, engineering, a PM and time to reach significance. Painted doors, which test the concept before the experience exists, and design mocks shown to users can invalidate many hypotheses first, so only vetted ideas reach a full test.

She describes herself as data-driven but says she would be seen as going by gut, since she leans on qualitative input alongside quantitative data. In college she worked in a lab where 95% confidence was mandatory, since false positives could shape education or health. In conversion work the stakes of a false success are lower, so she is willing to use lower confidence levels, especially if that doubles the number of experiments a team runs in a year.

She insists the validation plan be set before the experiment, so teams don't fit the data to a hypothesis or run tests without one. With a looser statistical bar, she wants qualitative evidence to corroborate results, for instance in the Twilio docs-page test, feedback that users felt more confident. She also argues that shipping too few experiments is itself a large risk: if you run ten a year and only two work, you are in a worse position, and she uses the 80% data to persuade skeptical data scientists.

Asked for a final lesson on experiments, Schaffer returns to the pressure to make data fit a story. Teams are often asked at the month's end what moved, and a failing experiment is painful after everyone worked hard on it. She says growth teams, and the leaders around them, must understand that the team exists to validate and find the biggest opportunities, which cannot happen on a weekly or even monthly timeline.

Short timelines, she argues, foster vanity metrics and data massaging, while teams that report over longer periods eventually show real success. She advises sharing the 80% fail rate with anyone holding you to short windows, and spends a good share of her time on this education. She suggests committing to what you can deliver over a year, with a low, medium and high bucket of bets, accepting that results are lumpy.

As an example, Schaffer describes how the developer-versus-not-developer signup question later revealed a growing group of non-developers who wanted to build with Twilio. Sales told her that if they could get such buyers from zero to one they could grow accounts a lot. The team built a way to deploy an app without writing code, called quick deploy on Code Exchange, effectively a create-your-own demo experience. It generated tens of millions of dollars in pipeline and gave sales something to offer non-engineering buyers.

Lenny notes that Schaffer moved from Twilio's product-led model to a more sales-driven Amplitude that wants more product-led motions. She sees product-led growth and sales as two sides of the same coin: one sells through the product, the other person to person. Companies need both, because buyers now expect to be sold by the product and large enterprises still buy from humans who listen to their needs.

The trap for sales-led companies, she says, is chopping up the enterprise offering, removing features and slapping on a price, while debating the pricing details. This treats PLG as a packaging problem. A good sales rep first understands the prospect's problem, and the product should do the same for self-serve users.

At Amplitude, she wants to reach small and mid-sized businesses and startups. In her experience such startups rarely have the right number of analysts, so the CEO and product managers end up building dashboards themselves and want reassurance on metrics, reports and benchmarks. Her takeaway is not to copy and paste or chop up the sales product, and to start with the customers, their different problems and their psyche, even while reusing existing knowledge.

On selling to developers, Schaffer says people strong on growth with other audiences often find developers a steep climb. Developers mostly skip the marketing site and go straight to signup, so any assumption that they already know your pricing or positioning fails. She compares them to IKEA buyers who tear open the bags and only look at instructions when stuck.

They also avoid sales to an unusual degree. A large well-known company signed up for Twilio, built a proof of concept and ran in production for months without speaking to sales, and an engineering team at a large retailer signed up with personal email addresses to avoid being contacted. She spoke to the first one only because they reached out to support about a missing delivery feature.

The reason, she says, is their responsibility. If a service fails, a pager wakes up their team, or the product doesn't integrate as promised, it is on the developer, and it can cost them their reputation or job. They can't take a salesperson's word for it and must build at least a proof of concept themselves, so they end up deep in self-serve before committing. Companies selling to developers must therefore invest in self-serve and treat growth as their sales function at that stage.

In the closing lightning round, Schaffer recommends *The Simple Path to Wealth* by JL Collins and *Atomic Habits* by James Clear, and names the Great British Baking Show as a favorite for its supportive competitors. Her interview question of choice is to ask about a recent ship that the candidate did not choose, since everyone has a success story, and the unpicked one reveals their frameworks.

The process change she credits is to be embarrassed by the first iteration, which speeds shipping and helps people celebrate the unpolished. For an Amplitude tip, she describes a video from her team at Rapid showing an anomaly in an Amplitude report traced through Segment to Hotjar screencasts of users doing that exact event. That let the team form concrete hypotheses without interviewing customers.