By “Why can’t we build it faster?!”
I’ve never met an entrepreneur in the software field who doesn’t ask themselves that question daily. For a lot of the past few years, I had an excuse: the constraint of capital. But, since April (when we raised $18mm), that argument’s invalidated. There’s an excess of cash on the balance sheet, and yet, from an external, customer perspective, it probably feels like we’ve slowed down.
Brad warned me about this. In our first call after the round closed, he said that the first year would be frustrating, as we invested in all those things we’d let slide over the last 5 years because revenue outweighed everything else. After 6 months, I finally understand what he was talking about, and why the pace of innovation, at least initially, slows down after investment.
There’s an apartment building on my walk to work that was demolished about 2 years ago, and in 18 of the last 24 months, looked mostly like a hole in the ground with tons of guys working in it. Then, like a shot from a cannon, 6 months ago it rose skyward to form a new, 10 story condo building that seemed to take no time at all.
That weirdly slow, long investment in the building’s foundation is because they’re (hopefully) doing it right. But, it sucks because from the outside, it looks like nothing’s getting done.
So, why is that true in software businesses? Especially startups, where lean methodologies and slogans like “move fast and break things” are so prevalent?
#1: Doubling the Team Halves the Speed (temporarily)
In January, the Moz team was 52 people. At the end of this year, we’ll be close to 110. Growing the engineering team, in particular, from ~18 to 50+ seems like it should mean a lot more bandwidth and ability to build great stuff, but the reality’s more complex. Each new engineer on the team takes up significant time from current engineers – hiring loops, training, the creation of documentation, and all the other things that accompany the onboarding process spell an initial decrease in production speed.
#2: All the Excuses to Fix Broken Shit Are Gone
When your revenue is all that stands between life and death for the company, there’s very little room to worry about anything else. That often includes things you know would keep you healthy and scalable and prevent future pain. Startups that need revenue are like college students cramming for finals. Unhealthy meals? Check. Skipping doctor & dentist visits? Check. Ignoring relationships that might help in the future? Check.
When the funding finally hit, the excuses not to invest in all those non-revenue, non-customer-visible projects melted away. Building functional analytics to understand our funnel, retention, and usage; crafting internal documentation and testing practices; staffing up our customer advisory board; investing in hardware to help our long-term margins – these and many more were now able to earn the prioritization they deserved.
#3: Building for Scale and Stability Takes Longer
We used to launch a lot of tools and features inside our product that were built to withstand a few dozen to a couple hundred simultaneous users. But,today, there’s 21,841 PRO users, and so everything we build for 2013 and beyond needs to 10X those maximum usage numbers at least, and hopefully 100X them so we don’t have to go through another re-building period in 18-24 months.
Hacking tools together is relatively easy, and it creates the expectation among technically inept CEOs like me about how long it takes to build something. Those expectations are useless and even dangerous when applied to a product that’s supposed to support 10s to 100s of thousands of users.
#4: “Lean” Development Becomes Irresponsible
The lean startup methodology is one that I love and constantly recommend to early-stage companies. But at Moz, it’s downright dumb. We can’t ask just a few users what they think – we need to know that a product we’re building (that could take 6+ months to develop and use 15-25% of the team’s talent) is the right one. Product/market fit is no longer the goal (at least not in the “Lean” way). The new product development and research cycle is longer, and leaving hacky/barely-working products live actually destroys brand value.
I’d argue that Facebook’s slogan of “move fast and break things,” while inspiring to many, may actually be a net negative on the brand. I hate moving slow, but I”m not sure I hate it more than building things that break. Certainly, for a business like ours, where retention and customer lifetime value are the big goals, I’d rather launch half as much and break half as often than launch twice as much and break twice as often. It’s hard to undo a brand perception of faultiness, and we’re already struggling here.
#5: That Big Dream is Finally Possible
When we took our first round of funding in November, 2007, I had this dream of building our own version of Google’s index upon which we could calculate PageRank and TrustRank and show anchor text and link data (since Google had removed the link: command several years earlier, and kept making less and less link information available). It took 11 months, but in October of 2008, we launched Linkscape (now Mozscape), and took off running.
A link graph and web index is a huge undertaking. It can’t be built and launched very iteratively, and we probably got away with one of the most minimum of minimum viable products.
In April of 2012, the same story’s true. It’s likely going to be ~March of 2013 (11 months coincidentally) until we launch our next really big thing (although we have a few more pretty big things coming before end of year, and we’ve had some big launches already like Followerwonk). Much like Mozscape, it would be hard to launch iteratively and show value, but damn. It’s tough and frustrating to see smaller and more nimble competitors able to build faster. It’s tough to know that you’re behind in some areas. It’s tough to know that decisions you made last year to “just ship it,” are hurting your ability to ship today, and, worst of all, it’s tough to explain to customers who’ve followed your story and know that you finally raised that funding and grew the team that there’s even more excuses as to why you haven’t built that feature they really want.
I’m super-crazy-over-the-top excited for the future, and I know the Moz team is, too. But, I suspect every scaling startup experiences pain like ours, and that’s why Brad’s words of wisdom seemed so prescient. If we can endure this pain, there’s an awful shiny light at the end of the tunnel.