When A/B Testing Became a Sailing Strategy—and Won
How fast feedback and fearless testing turned a race around
Imagine your cross-functional team of PMs, designers and engineers as a sports team. What team would they be? For me, I see an analogy with a high performing sailing team.
Last fall my sailing team entered the final stretch of a race in last place - and then a/b tested our way past 3 boats!
👋 Hey, I’m Alex. I write Shipping on Fridays to explore the craft of how great products get built. In honor of the summer, this week’s Shipping on Fridays highlights the similarities I’ve noticed between a high functioning sailing team and a cross-functional product team. If you’re into learning, product or design, this is for you.
The tiniest bit of background on sailing
I race on my friend’s 33-ft sailboat on weekends. It has a top speed of about 9-10 knots (~12mph) surfing in 15 knots (17mph) of wind.
Like a product team, each crew member has a specialized role — the skipper steers, the main trimmer controls the big sail, the jib trimmer fine-tunes the front sail, and the bow crew (me) handles everything up front to keep the boat moving fast.
It’s a perfect cross-functional setup: different skills, constant communication, and one shared goal — make the boat go faster.
Our a/b testing win
Last fall we found ourselves rounding the 2nd to last mark in last place. It was the sailing equivalent of being down 4 runs, starting the bottom of the ninth inning in baseball. Heartwrenching.
Even worse, since everyone we race against sails the same type of boat and we all use the same wind - there’s no way we could just “push harder / faster” to catch up. Morale was low. It’s one thing to lose, it’s another to see no clear way to win. We had to think differently.
The skipper called out “how might we pass these boats ahead of us?”. Without thinking about it, he had begun a cross-functional brainstorm. We already had a strong culture of open communication and learning on our boat - so it felt natural for him to ask for ideas.
Someone suggested shifting our weight in the boat. There was agreement that we should test that, so we did. We moved where we were sitting in the boat to give the boat a little more heel and watched our speedometer to see if there had been any change. After a few minutes it was clear - our speed had consistently ticked up a little bit. We had our first winning test!
Throughout the remainder of that race we “launched” 3-5 more “tests”. For instance, the jib trimmer suggested we use the outboard leads to trim the jib. We tried it, waited for a speed reading and got another tenth of a knot.
Some of our experiments worked, a bunch more failed, but the winners ended up netting us enough incremental speed to put us back into the competition and pass two or three boats before the end of that race. A remarkable achievement!
Lessons Learned
That race taught me an important lesson that I take back to work: speed (winning!) comes from learning faster than your competition.
We didn’t have a faster boat. We didn’t have more resources. We had a team with the resilience to turn around a bad situation. The culture of open communication and continuous learning we had built all summer allowed us to have that impromptu brainstorm. Each test was lightweight and fast — and together, they stacked into a win.
In product teams, it’s the same. We’re often under-resourced with ambitious goals. We must test and learn to discover the solutions that really move the needle. And those tests don’t need to be high fidelity or production code to learn (see related post).
Lesson: Build an open culture where anyone can suggest a test. Run small, iterative experiments. Stack the wins, and you’ll make big comebacks possible.
Very cool analogy! There are good takeaways here especially regarding testing often. Sometimes the tests might not be as fruitful so you fail fast and try something else. Learned a lot about sailing too this morning!