Gnip: What's worked well, and what hasn't.

Gnip's almost a year old. That combined with a great week which included a stellar board meeting, technical clarity around specific areas, business/requirements clarity around specific areas, and an impending big release motivated this blog post.

We have built an amazing back plane that's driving a true marketplace for modern data, while solving fundamental data access issues on the network today. We have a growing revenue curve with tons of blue sky ahead. We're turning our back on verticals that would kill us, and embracing the sweet spots. It's always a difficult road ahead, but just like 2008, 2009 is going to be a killer year for Gnip. I'm so stoked to be a part of this.

I wanted to take a quick look back on 2008 and outline the positives and negatives that stick out in my mind; maybe you can make use of them in your startup.

On the plus side we...

• Never compromised on hires, despite delivery schedule impact.
• Hired experience, breadth and depth. While expensive, it sure beats babysitting and training kids when you have to be executing a mile a minute.
• Leveraged "the cloud" for ultimate hosting environment flexibility.
• Solved real problems in the industry. One of our investors, First Round Capital, sums this approach up well on their website: "Companies must provide a unique solution to an existing urgent need. We don't invest in companies which try to change consumer behavior or create a new consumer need."
• Made pragmatic decisions to cut features that were weighing too heavy on operations, despite vocal community suggesting we do otherwise. Don't drown yourself.
• Let the business definition, and customers, evolve naturally. Steadfast tunnel vision would have left us in the dust.

On the minus-side we...

• Ran too long with too big a feedback loop between business, technology, and customers. From software development, to business evolution, small, fast, tight feedback loops are fundamental. Hell or high-water, make certain any open questions get nailed down immediately.
• Didn't "load test" all possible scenarios (difficult to predict no matter how you slice it). Until your business model is crystal clear, pressure every edge of your software so you know where the sweetspots are, and where the fragility is.
• "Pragmatically" pair-programmed for too long. Wishy-washy process led to confusion, lack of clarity, and inefficiency. Once we drew the line in the sand and declared to ourselves that we were _a pair programming shop_, no questions asked, the seas parted and clarity became crystal around the process.