I re-listened to Reid Hoffman’s Masters of Scale episode 4 (Imperfect Is Perfect) on the walk from the office to North Station last night. This episode highlights the criticality of putting your product in front of customers early and often. The topic is an obvious one for Reid, who is known for saying: "If you're not embarrassed by the first version of your product, you’ve launched too late.” It’s a short but high impact episode, and one which connects with my own personal experiences. It also has the perfect guest: Mr. Move Fast and Break Things himself, Mark Zuckerberg.
The day after leaving my job at Sonian in 2012, I was hacking code to test my earliest assumptions on cloud management. I put my first product in front of customers less than two weeks after starting full-time on the business idea: an Amazon Web Services reserved instance analyzer that I announced via a blog post. It was simple, crude, and as I would learn from its early users: incredibly cumbersome. I remember one of my earliest users telling me he didn’t like it, after which he gave me insightful feedback on exactly how to fix it. I found this pattern repeated over and over again, making me realize the only valuable product feedback you can receive as an early entrepreneur comes from real users. It didn’t seem to matter how crude or incomplete the feature was - just the act of connecting a user with a product they needed to work unleashed a flow of valuable feedback.
The second product I launched came four days later, and was an AWS security group analyzer, which I again announced via a blog post. This process of hack and launch would go on near continuously for the next year, as I calibrated my product offering based on the feedback from early users. During this time, I tested countless new ideas, some of which worked and many that did not. One feature I was particularly disappointed in failing was a collaboration features that allowed users in a team to add comments on anything in the platform. To this day I still don’t understand why that experiment failed, but as I liked to remind myself: we subsume all opinions at the altar of the customer.
I called the approach we took to building CloudHealth “iterating in the presence of customers.” To accommodate it, I adopted an technique to defining requirements before creating stories, including in the proposed requirements the proposed release phasing to test assumptions and ensure we shipped early and often. Our goal with a first phase of a feature was always to find the smallest possible subset of functionality that would be used by at least a few customers the day we released it. This was a critical threshold, since the greatest risk in software development is building something that does does not matter.
If agile was a road trip, traveling from Boston to San Francisco is often seen as a series of iterative sprints, during which you drive successively closer to your destination. But iterating in the presence of customers teaches you that while it’s important to know a destination, just starting on the road and asking questions almost always takes you to a different and better place than you originally planned.