July 25, 2014
The Anatomy of Heroku’s Product Team
Peter is a co-founder of the Heroku Postgres product team. For over three years he has been responsible for designing, developing, and opera...
On April 27th, 2016, Heavybit member company Librato held their SF Metrics Meetup at our San Francisco Clubhouse. Below is a video of Opsee CEO Cliff Moon’s talk ‘So You Want To Start A Monitoring Company’ as well as further thoughts from Cliff himself.
A systems engineer without a good startup idea inevitably winds up doing monitoring. — Jeff Hodges
I first moved to San Francisco in 2007 to join the burgeoning tech scene. The first startup I worked for was a company called Powerset. It was a tough move that we managed by the skin of our teeth and quite a bit of help from friends. My second day on the job — my wife & child weren’t even in town yet — there was an all hands to announce that one of the founders was getting fired. Welcome to startup life.
About six months after Powerset got sold to Microsoft I, along with a few friends, started working on a nights & weekends project. The early direction was very vague, essentially just that we wanted to build google analytics for network data. After about a year and a half of hacking away at that, my golden handcuffs finally came off and I quit to work on it full time. Nine months and an exhausted savings account later, and we had a prototype good enough to get funding.
Along the way I learned quite a few things about startups in general, and monitoring companies especially.
Monitoring companies almost always have engineering challenges that other kinds of startups can put off for a long time. Both scale and reliability have to be taken into account from the very beginning, otherwise you don’t have a viable product. And once you do start adding customers it’s a never ending battle to meet the incremental scale challenges. Having a large, highly skilled and motivated team is just table stakes for sustaining the infrastructure. This might be ok if you can charge enough for the service to pay for a large and experienced team. However, it’s very easy with a monitoring company to get this equation wrong and end up in a place where you have no ability to ship new features.
One of my biggest lessons from Boundary was to consider the product from the perspective of the customer first and foremost.
It sounds self-evident to people with a product background, but for a systems engineer it takes effort to look at things from that perspective. When you start from the technology first approach as we did, there are few opportunities to ask a question like, “do we even need to build this thing right now?” Ultimately we made the mistake of assuming that the market would reward us for solving a hard problem. However, the market doesn’t care about your work ethic if you aren’t solving a widespread customer pain.
At the end of the day the success of any startup is going to be determined by some combination of luck, skill and determination. To me, the one part of that equation that we can’t control, luck, should be the thing that keeps us humble. We can’t often predict what we’ll encounter along the journey, and we certainly won’t know our actions for mistakes until they’re in the rearview mirror. We can only promise ourselves that as we move forward we’ll make different mistakes this time.