Why it took 12 weeks to ship an MVP I thought would take 3, Hacker News

Why it took 12 weeks to ship an MVP I thought would take 3

When I started working on (Box CI) I set the goal of shipping an MVP within 3 weeks. It actually took 12 weeks to ship the MVP.

That’s quite a big difference – 4x longer than the original 3 week goal. Now, sure, that goal was purposefully over-ambituous to drive me to get the MVP out as fast as possible. By nature I didn’t have 100% confidence that I would hit that. If I did, I would have reduced it. But still, honestly I thought that shipping within double that time, 6 weeks, was approaching 100% confidence. But it took doublethat– 12 weeks.

Part of the goal for me with building Box CI is to apply lessons I’ve learned from my past attempts to build and launch products. That’s why getting the MVP out as quickly as possible was such a priority for me. In the past that’s always been an issue – I’ve worked on the MVP of the product for a pretty long time, typically 6 months, and added a lot of stuff to it all without ever releasing it or seeing if people are interested.

I wanted to do things very differently here and make the goal getting feedback as soon as possible to see if I’m building something useful, or even the right thing at all. I don’t want to spend 6 months building something, get to the end of the 6 months, and find that it was mostly a waste of time. Well you know, apart from the technical skills developed and fun had in building the thing – the time is never truly wasted.

With that said then, let’s start by saying that 12 weeks – 3 months – is actually the shortest time its taken me to ship an MVP of any product I’ve built. So I did apply that lesson. But, it was still a fair bit longer than I’d thought it would take. Even when you learn from old lessons you can still create new ones! I guess you’re never done learning.

In this post I want to explore the reasons why a thing that I was really confident could be built in 6 weeksin theoryactually took 12 weeks in practice.

Double it and add 2 weeks)

It’s kind of a meme in software engineering that when you estimate how long anything will take, you can pretty much double it and add 2 weeks to get therealestimate. Everyone who’s worked in software laughs when they hear that, because while obviously a bit absurd, it’s also literally true a surprising amount of the time. And the futher funny thing is that even with knowledge of this rule, it’s still true. It turns out to be really, really hard to actually apply lessons learned and stop yourself from repeating the same mistakes.

To be honest, I think a big slice of those extra weeks came from this. The hard thing about building something is that it very easy to think about how something will look and behave broadly when it is done, and that makes it seem like it’ll be easy to build. You can picture the complete thing without really focusing too much on the details that make it actually work. That’s almost by nature. When you’re using a product, ideally its behavior and the way you interact with it is pretty simple. All the difficulty is abstracted away from you. That’s actually kind of the point!

But when you’re building it, you do have to really focus on those details and build them all out one by one. Sometimes those details themselves are abstractions over even more details that you have to build from scratch or plug together from existing solutions. I sometimes describe this as fractal complexity. When you dive into the details you find even more details that you hadn’t even considered before – the complexity only reveals itself when you dive in and explore the problem.

I realize this is kind of a catch all excuse-y type reason, that’s not specific to Box CI (I’ll get to some specific stuff later) but I list it first just in the interest of honesty. I really think that this was the main reason it took a lot longer than I thought it would. In trying to apply one lesson (ship fast) I forgot another (estimating how long software takes to build is really hard, maybe impossible).

Stuff comes up

OK, now for another lesson in theory vs practice. I think this is pretty generic too, but also very relevant to anyone bootstrapping a company or trying to build a product. I think when you’re planning things out, it’s very easy to see the expanse of weeks ahead as blank slate that can be filledhowever you chooseand optimized according to the priority you’re going to think about now, at the point of planning. In practice though, stuff comes up, and you often can’t predict what and how.

You have far less control of your time than you think you do, especially months in advance. You have to provision for this, because it’s very very unlikely that the plan you set out won’t be delayed and interrupted by things you haven’t thought about.

This can be other work stuff, but it can also just be general stuff. In my case, there were a few of things like this during the 12 weeks I was building the MVP

Moved apartments.I don’t know why, but every time I move I’m always surprised by the level of effort and time involved in doing so. It’s a lot of things added up over quite a long time, really, but I’d guess that added together it’s probably a full work week of time taken packing, moving things, unpacking, etc. When making the estimate of 3 weeks for the Box CI MVP, for whataver reason I didn’t even factor this in. I always imagine myself ‘working around’ these things, and then when you get to them you realize that’s really dumb, there are only so many hours in the day.
Other work commitments.A few days a week I do contract and consultancy work to get some income whilst trying to bootstrap Box CI. Again, when planning, I had assumed this work was going to stay at a flat 2 days, maximum 3 days per week. I think you can tell where this is going! Roughly 10 weeks in, there was a spike in my contract work which meant I had to be on it basically full time for about 2 weeks, during which time the launch had to be put on hold. 2 weeks – that alone added about 20% to the launch time.

The lesson is, when setting goals , always provision for unexpected stuff coming up that just has to be prioritised. You might get lucky and this doesn’t happen, but with an estimate time measured in months it seems fairly likely that it will. In future, I’ll be learning from this and adding a good 25% extra onto any estimates for multi-week goals to provision for things like this.

It’s got to be viable

About 6 weeks in, Ididactually have the MVP functionality done. I was right on the verge of shipping, thinking that it would only be a matter of days. Then I stopped, took a step back and looked at the product from the perspective of someone who would want to pay for it.

What I had was definitely minimal, but it wasn’t quite viable. It made sense to me, because I’d built it and already knew how it was supposed to work. But I realized a couple of things

The CLI had no documentation
The product did not look like something anyone would want to pay for

Point 1 seems like a very obvious thing, but when you’re in the process of building something, living in it day after day, sometimes things that are very obvious get missed. Like, of course I couldn’t release this thing without docs. How would anyone know how to use it? Yes the CLI worked, the code was even open source, but it would have zero utility in practice until documented. It was minimal, just not yet viable.

So I set about documenting it. And oh, what do you know, documentation turns out to be one of those fractal problems I discussed above. Seems easy right – it’s a CLI – just document every option and you’re done in half a day. That’s *** I thought too.

But then you realize that each individual option is its own thing that requires thought to explain, and crucially,interacts with all other options. It’s not enough to explain it in isolation. You need to tie everything together. You need examples. You realize from doing all this that there’s a simpler way to name or combine options, you go back and make that change and have to update all the examples, explanations, etc.

Then there’s the presentation. The same docs need to be presented on the CLI itself via– help, on the website, on Github and on npm. They’d probably better look more or less the same on all of those to be consistent. You’ve started with one, and now have to figure out how to make it look similar in the others. Markdown, HTML / CSS and plaintext are quite different media for presentation, this is not a trivial problem. Remember how this was going to take half a day? Fractal problem: -)

So, having done the documentation, I was once again ready to ship. At least ostensibly. This might have been around 8 weeks in. But when I was thinking I was done and was going to ship the next day, I had a conversation which really made me sit back and think, and decide that I wasn’t. The conversation was with a designer at my coworking space – he was kind enough to sit with me whilst I gave him a tour of the product and give me some design related feedback.

Now, I had decided early on that the design was going to be purposefully very simple. Almost just like a mockup, to get the product functionally working as fast as possible. This felt smart, and it also felt productive, because design takes a lot of time and effort and not having to worry it about it much saves you a lot of time and effort!

I also had this piece of advice that you hear a lot in the startup world in mind from the beginning:If you’re not embarrassed by your first version, you shipped too late. Doing a simple, fairly ugly design almost felt like a badge of honor, if anything. I’m doing this right, because it looks amateur. I am embarrassed by this, that’s a good thing!

But when I talked with this designer, I realized that actually this was completely wrong. It might be that this advice makes sense for certain types of product, but it just really doesn’t at all for a professional tool you’re going to pay for. Nobody is going to pay for something that looks amateur and unfinished. If you feel embarassed by it, why on earth would you expect somebody to pay for it?

Sometimes it takes a conversation with someone else unfamiliar with your work to really question your fundamental principles. You hear yourself saying things out loud, and you realize they’re just wrong. It’s like if you merely think these things, you can more easily ignore them and rationalize them away. I was walking him through the product and constantly caveating everything with “I know this looks pretty amateur”. He didn’t even have to say it, I led myself there: this thing was not ready to ship.

I thought about this a lot that night, and came back the next day and just started fresh with the design. I think in total this probably extended the total build time by about 2 weeks (design is hard). Looking back, I think this was the right decision. When I was in the middle of this work, though, I was questioning if I’d made the right call. I started to think again about the mistakes I’d made in the past with perfectionsim – tweaking things for the sake of tweaking them – getting things to 95% when 80% would have been fine.

I tweeted about my doubts over this and got areply from @taykcranewhich made me decide that actually, I was doing the right thing. The image he links in his tweet sums up my intuition about this really eloquently. A picture as they say is worth 1000 words.

The way I eventually came to think about it was that it’s all in how you interpret the wordviable. Viable only has meaning within a context. Viable doesn’t simply mean ‘it works’. That’s necessary but insufficient. The context is much broader than just that. The product may work, but that’s pointless unless people use it. What is the goal of the product, to work in the abstract, or to solve people’s problems in practice? If nobody wants to use it, though it may work, it’s not doing anything useful – it’s not viable.

Lessons

To reduce everything I learned here into a few bullet point lessons is difficult, but I think a good exercise for the future. Some of the lessons here were new, some of them simply refinements of lessons I already had partly learned working on other things.

Building things takes a lot more time than you think it will! It’s honestly probably always wise to simply come to a reasonable estimate (guess) of how long it might take roughly, then double that, then still don’t be disappointed if you go over!
Don’t use MVP as an excuse to avoid doing necessary things like working on design. Yes, you shouldn’t be overtly perfectionist and you should ship, but don’t go to the other extreme and purposefully disregard things like decent design that actually make your MVPviable.
When you’re working on an MVP, be mindful of the other commitments you have that may divert your attention. Stuff happens. You can get distracted or drawn into something else for weeks at a time. You’re not building your MVP in a vaccuum. Be honest with yourself about that from the start, so you don’t feel guilty about it when it happens.