Founder Lesson
What I like to believe about startups is that two passionate founders who love a problem have a unique insight in a space and work on that problem until something clicks.

But lately I’ve been thinking about an alternative path.

What if founders just try to solve a problem without a big mission from the start? What if they don't have unique insights in the beginning? What if the entire process is more focused on iterative execution and customers instead of disruption and a big vision?

This is how Slack was created.

In this podcast the founder of Slack describes how he and the team pivoted from a gaming startup into Slack, one of today’s fastest growing startups.

Here are a few characteristics of this approach...

1) Focus on execution and iteration with a small group. The original Slack team was working on a game. The technology that became Slack was the internal team communication tool that they used for themselves while they were building the game. In other words, they spent a few years with dozens of people just solving their basic internal communication problems. No grandiose mission around the product that would become Slack.

2) Important insights are discovered over time. Because Slack wasn't the original idea, they didn't have any major insights at the start around that product. Their unique insights around transparency and the “day one problem" where new employees don’t know the history of the company emerged over time.

3) Timing matters. This approach naturally takes longer because you aren't creating hypotheses and testing them. But - at least in the case of Slack - they needed the world to evolve in order for the timing to be right for a tool like that to succeed.

We continue to incubate our own startups at Switchyards. As we step through these spaces, we try to focus more on first principles than a strong point-of-view. It's not always possible (or the right path), but - as a founder - I'd encourage you to always start with first principles for a small group of users who should love your product and then grow/build from there.

Sidenote: If you enjoyed this post, you might like this one as well.

Sidenote: Points #1 and #2 in this fantastic post from Steve Blank point out some other reasons to approach problems in this way. The bottom line...don't assume anything about customer behavior or product.

Get Right to the Lesson
I’d recommend listening to the entire thing, but to get right to the point go to minute 2:24 of this podcast.

Thanks to these folks for helping us all learn faster
Stewart Butterfield (@stewart), co-founder & CEO of Slack Technologies (@SlackHQ)
a16z (@a16z)
Sonal Chokshi (@smc90)

Please let me and others know what you think about this topic
Email me privately at dave@switchyards.com or let's discuss publicly at @davempayne.