Are you trying to win?
It was in a rare moment of stillness in a game of ice hockey — a sport which is usually non-stop intensity — that I had a realization that would pay huge dividends in my life.
I held the puck, and we were in the enemy zone. I was down on the goal line, about 10 feet to the side of the opposing net. My four linemates, and the 5 skaters on the enemy team, were set up in the zone, waiting for me to make a move. But noone was coming for me. So I didn’t make a move immediately. And as I scanned the zone, looking for the perfect pass to make to set up a scoring opportunity, I realized that I had a direct line to the goalie right now. For some reason, all ten players on the ice, as well as the goalie, didn’t expect me to take that route. It must have been that we were so habituated to certain styles of play that we expected that I would set up one of the normal scoring opportunities. But when I saw nobody between be and the net, I realized that I had a decent chance of scoring right there. So while continuing to scan the zone as if I was looking to make a pass, I snapped a quick shot to my left. It hit the goalie and bounced into the net. It was so obvious in retrospect. But somehow we were all surprised by it. The captain of my team, as we skated off the ice, asked me “Where’d you learn that?”
Since that day, many times I have asked myself: am I trying to win right now? And often, I’m not. Often I find that what I’m trying to do is carry out some process or procedure. But if I break out of that and let my brain try to solve the problem of winning right now, it might find a better solution.
As a product manager making mobile apps and games, this technique has come in handy. Right now my team is making a game prototype, and we’ve decided to shun the normal plodding mode of development by A/B testing in favor of a win first, figure out how we did it later approach. We’re going all out after the goal of building a game that people around our company enjoy playing. And we’re giving very few shits about how scientific we’re being along the way.
And because of that, we’re learning extremely fast. We’re six weeks in, and we now have a game that’s gotten people in our company more excited about our games that we’ve ever seen in the past. And at the same time, our intuitions about what will work and what won’t work are improving at a meteoric rate.
There’s a tradeoff that every development team must face between scientific precision and speed. If you want high precision, you can build and roll out each feature one at a time behind an A/B test to isolate the effect of that feature. The problem is that this is super slow. That’s especially true if you’re a company with a small userbase and it takes you a long time to get enough data to call a test. And what that slowness means, in practice, is not that it’ll take you longer to get to test the features you want, but rather that there are many features that you’ll never get to test. It’ll just take too long to get there.
On the other hand, if you want high speed, then treat it like rapid prototyping. Get crude learning on hundreds of variables, rather than precise learning on a few variables. Use your intuition. Be scrappy. Hatch a scheme. Do what it takes to make the product fun, now. When you’ve got something that your testers are excited to use in the way you want your audience to use the product, that’s when you step back and figure out how to emulate what worked there out in the wild.