What I Learned Building Medium (So Far)
As of November 2012 We’re now eight months into building Medium, having started in earnest in February of this year.
As of November 2012
We’re now eight months into building Medium, having started in earnest in February of this year. In August, we launched what I call the “preview” version—which included viewing content publicly and creation for a small whitelist of folks. No real homepage, discovery, profiles, or many other important features.
We’re now in the process of rolling out several of those things, as well as changing other stuff. So, we’re still in the nascent stages. We haven’t opened up, tried to grow, or, certainly, proven we have product/market fit.
Still, it’s been educational. Here are some of my observations this time around:
Even if they’re awesome, having too big of a team will slow you down.
One of the luxuries we’ve had at Obvious is the ability to hire an amazingly high-caliber engineering and design team. In fact, I was so hard-wired from Twitter to hire every great engineer or designer I could find, we built a team of ten or so amazing folks before we knew exactly what we were going to do. Yes, that’s a tiny company—but a lot of people to be in “garage phase” with.
I always assumed, even if we had a few too many people to start, we’d quickly need all of them as the product began to take shape. This has proven to be true. We’re now about fifteen, everyone is extremely busy, and we’re looking to grow. But I underestimated the cost of having too many people around the table in the beginning.
Capable people need meaty challenges. There are no meaty challenges in the very beginning except defining what it is exactly (or approximately) you’re doing. That’s a job you can’t divide up too finely. And the communication costs of keeping everyone in sync with the daily changes is daunting.
Nothing clarifies focus like a date. (Or: If you don’t have a tough constraint, make one up.)
Historically, I’ve been constrained by engineering resources and money. These are good forcing functions to drive simplicity. It’s caused me no end of angst that I couldn’t make our products as great as I wanted to in the past.
With Medium, we have an engineering team that can build anything, matched with large ambitions, and plenty of capital. How do we ensure we don’t create something overly complex and/or fail to ship at all? By picking a date.
The reason we did our preview launch in August was simply to get something out the door. As soon as we picked the date and a minimal feature set, we got rid of loads of other features we were playing with (some of which we’ll bring back, some of which we won’t). We also identified and built a bunch of infrastructure we’d need to host real users. And we got more done in less time than I’d ever seen any team do. It was magical and fun. Before we had the date, frankly, we were drifting.
Getting something out the door was key also because it clarified our vision and focus more. We were making fewer guesses—not because of explicit user feedback and data analysis as much as just observing and experiencing real-world usage. As Matt Mullenweg put it,
Usage is like oxygen for ideas.
Designing a product from scratch is always hard.
This is my third or fourth publishing platform and fourth or fifth company (depending on which ones you count). It’s the culmination of ideas I’ve been thinking about as far back as 2000. And yet, it’s a struggle to figure out exactly what Medium should be.
Things that are hard
- Boiling down over a dozen years of ideas and observations (and those are just mine, let alone the rest of the team).
- Analyzing the current landscape and predicting where its all going.
- Wanting to be extremely ambitious, but knowing the value of simplicity (and the pitfalls of trying to be too many things to too many people).
- Having your sights on aspirational goals while taking into account the realities of how users react.
- Wanting to move quickly to try stuff and yet embrace your team’s perfectionist tendencies.
- Knowing that some “little” decisions you make today will have enormous consequences down the road—and some won’t really matter.
This the process of product design. Or, as Steve Jobs put it:
Designing a product is keeping five thousand things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently.
And it’s that process that is the magic.
I’m no Steve Jobs, but my confidence about product design has gotten much stronger over the years. At the same time, the bar I hold myself and the team to is higher, as well—so it hasn’t gotten easier. We sweat all the details, and we’re constantly unsatisfied with where we’re at. Welcome (again) to startup life.
Stay tuned to see how it unfolds.