Successful Product Development, part 3: Planning

October 10, 2016

Planning is simple, right? You figure out the order of doing things, figure out how long each of them is going to take and stack them on top of each other in a Gantt chart. What could go wrong? Turns out a lot, but in this blog post we’re focus on figuring out how long stuff is going to take.

Not to scare you in the beginning, we’re gonna start with difficulty level: easy and we’ll look into something simple — a drive to the airport. There are a few terms to explain here:


That’s the building block of our “how long will it take?” problem. In our example when someone asks you how long does it take for you to get to the airport from your house, it’s fairly easy to answer. It’s a 30 mins drive, so you say: 30 mins. That’s an estimation.

But is it really gonna take just 30 mins? If you get a phone call from a friend — I just landed, can you pick me up? — are you gonna be there in 30 mins?

Of course not! You’ll have to put your shoes and a jacket on (unless you live in Barcelona!), find your car keys, get your car out of the garage (which might be tricky if you live in Barcelona!), park at the car at the airport, walk to the arrivals hall, etc. Easily another 15 mins.

So we just had a 50% error on estimating something so simple as a drive to the airport. Let’s take it up a notch and talk about commitments.


Let’s say your parents are coming to visit and you want to pick them up from the airport. They’re supposed to land at 15:00, so you want to plan what time do you need to get there. Because of the previous exercise we just did, you know that getting to the airport doesn’t really take 30 mins, but rather 45. Then you take into account that they might land 15 mins earlier, so it’s better to adjust for that margin. Then (fortunately!) you remember you’re almost out of gas, so you need to stop at a gas station — another 10 mins, etc. It all adds up to an hour and ten minutes, right?

That’s your commitment: you’re going to start your drive to the airport at 13:50 to be there at 15:00 when your parents land. At first it sounds a bit silly, taking into account the original estimation: 30 mins. But when you look into the whole context of the “airport pickup project” it makes sense.

Now, let’s move on to the real hard stuff…


Example of a real deadline is booking a flight for your holidays. If you’re gonna be late to pick up your parents, you can just call them to wait for you and it’s not a big issues (hopefully!). There’s no way an airplane’s going to wait for you, though. So we better plan ahead!

We already know the drive itself takes 30 mins (the original estimation). We know we need to add extra 15 mins for parking, getting all your stuff, etc. We remember we might need to stop at a gas station, so it’s already 55 mins. I won’t even get into the subject of security checks and the size of the airport and time it takes for you to get to your gate, etc. Nobody can reasonably estimate that! (see what I did there? ha ha!)

Let’s just simplify and say we want to be 30 mins earlier than (we think) we need to be. Also, let’s think of the traffic — what if there’s an accident on the highway? Let’s just throw in extra 10 mins for good measure. And who’s gonna check you turned off all the lights and radiators, etc.? You — so another 10 mins for that (and for double-checking that you REALLY closed the doors behind you).

Total: one hour, 45 minutes. Just to take a 30 mins drive. Wow, that’s a lot. But that’s the **nature of hard deadlines **— if it’s a date that you REALLY need to hit and don’t want to be late, you need to think about everything that might go wrong and add sufficient margins to account for it.

Keep in mind that some people talk about soft and hard deadlines, instead of distinguishing between them and commitments. For me that makes no sense. If the date can be changed by you, then it’s something that you commit to deliver at a particular date. If it’s out of your control — only then we have a deadline.

Estimating is hard

See how the original estimate exploded into almost 400% of the original value? And it was just a really simple example. Let’s go to difficulty level: medium and talk about putting a child to sleep. Even though putting a child to sleep is pretty chaotic and depends on a lot of things — it’s a fairly defined process (the child should be in bed, sleeping, washed and all remnants of dinner cleaned up) and something that you do every single day, so you should be able to say how long it takes, right?

You’ll probably guess a value, but if you were to write down how long it actually took every single day for a month, you’ll see that you’re estimate is off by a long shot from how long it CAN take. And the deadlines need to take into account the pessimistic version if you want to meet them.

Finally, difficulty level: hard and let’s estimate some software projects. The process is at least as chaotic as getting a baby to sleep (the designs are changing, the APIs break, scope changes, computers break, software updates ruin your build setup, etc.) and to make it even harder — you’ve never done it before! Every single project is different, has different requirements, technological decisions, designs, team, etc. So if figuring out what time you’ll child we’ll be asleep is difficult, software projects are a nightmare!

So, how do we stop our timelines from exploding?

Now we can see the importance of the previous lesson: keeping scope small. All those small changes add up. Every single one of them will need some extra padding to make sure we stay on track, something **always** will go wrong and break your plans, so your safest bet is limit those moving parts. So, cut all those things out, however small they seem.

Another important thing is communication: when you ask your development team — how long is that thing going to take? They’ll answer just like you’d answer how long it takes to get to the airport: it’s a 30 mins drive. It’s up to you to interpret this answer and adjust your commitments and deadlines accordingly. Communication is a huge topic in itself, so we’ll touch on it in the next blog post in this series. Stay tuned!

Sidenote: two days after writing this article I almost missed a plane, because I was late for my train to the airport. Even with the best analysis you can still miss your mark!

Want more?

If you liked this post, why don't you subscribe for more content? If you're as old-school as we are, you can just grab the RSS feed of this blog. Or enroll to the course described below!

Alternatively, if audio's more your thing why don't you subscribe to our podcast! We're still figuring out what it's going to be, but already quite a few episodes are waiting for you to check them out.

Blog author: Brains&Beards


Mobile application development studio

Happy puzzle phone

More Brains and Beards stories