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 no one was coming for me. They were waiting to see what I’d do. So I didn’t make a move immediately. And as I scanned the zone, looking for the perfect pass to set up a scoring opportunity, I realized that I had a direct line to the goalie right now. For some reason, all eleven players in the zone, myself and the goalie included, 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 me 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 moved towards the goalie and snapped a quick shot. The puck found its way past him and into the net. It was so obvious in retrospect. But somehow we were all surprised by it. The captain of my team, as he gave me a fist bump, asked “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 via 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 moving extremely fast. We’re six weeks in, and we now have a game that’s gotten employees in our company more excited about the company’s products that we’ve ever seen. 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 here out in the wild.