How quarterly plans made a huge difference for our startup

Gilad Avidan
Designing the Obvious
5 min readJan 20, 2017

Building a startup requires a lot of focus. But it’s not enough to just focus on one thing like crazy (ignoring everything else): you need balance. Over enough time, I’ve found that our team would be stuck in one of two modes: either we’d be sprinting for weeks to finish a major feature (sometimes discovering that we should have been working on something else), or we’d spend relatively idle time on less-important tasks, trying to design or figure out what the next big thing would be.

I knew that the problem stemmed from lacking a formal long term plan, but I didn’t want to lock myself into something too restrictive. After all, we’re supposed to be a lean startup, right? Do we even need a plan?

Well, it turns out that a good, startup-ready planning methodology can really help out. Here’s why:

Problem #1: No planning leads to busywork

Every worker needs to know what their upcoming tasks are. If you leave planning to the last minute, you need to come up with something quickly or lose precious work time. Here’s a conversation we’d keep having:

Engineer: So what are we doing this week? I just finished with X.
Me: Hmm… (scrambling) … maybe you can work on Y?
Engineer: Really? I thought Y is pretty unimportant. Why don’t we start working on Z?
Me: Well, Z isn’t planned yet. Maybe work on Y until Z is planned.

The result is wasted time working on unimportant but simple stuff (read: busywork), and workers bugging you to give them new tasks, which you have to constantly struggle to come up with. Over time we’re talking loss of focus and lost morale. Ultimately you end up looking back at the past few months and thinking: where did the time go?

Problem #2: “Important” projects take way too long

When we weren’t scrambling to plan new things to do, we’d be stuck in overlong sprints working on some big feature that seemed to never truly get done. Sometimes we would spend weeks or months on a single big release, neglecting smaller, helpful projects. Everyone was waiting for the big thing to be finished so that we can move on.

Sure, you want to make bigger bets; but how do you reign these projects in?

Problem #3: Rising technical debt

If you spend all your time on doing big projects or on worrying why you’re not doing big projects, you never get time to cleanup old code, or that duct-taped system you built to finish a release. Coding in a startup often means compromising on code quality (if you don’t, you can probably be going faster), but you have to stop once in a while and do some maintenance or you’ll be stuck with terrible, patchwork systems forever.

The Solution

  1. Plan in quarters. A quarter is long enough (13 weeks) that you can make meaningful bets, and it’s short enough that even if you stick to your plan blindly you’re probably not going to miss any opportunities. At the end of the quarter, take a beat, look back and see what you missed (more on this later).
  2. Make a realistic list of what you want to accomplish in the upcoming quarter. What we would do is try to answer the question: “what would we be stupid not to do in the next 3 months?”. Try to trim the list down to 5–6 items max. It’s just 3 months after all.
  3. Divide each quarter into 13 week-long slots. For each slot put down what you’d be doing that week, as a short title. For example: “new landing page”, “3d rendering”, etc. If you need more than one week to complete a project, you can assign it two slots, either contiguous or not. Don’t make bets that take up more than two or three slots in a quarter.
  4. At the end of the last slot for a project, you ship. No exceptions or lateness is allowed. Sound stressful? Well, working with constraints will do wonders for your productivity. You’d be surprised at what you can accomplish in two weeks if you plan correctly and you focus.
  5. Leave week #6 and #12 open as “overflow”. These weeks are left open on purpose so that you can take care of either projects that you just didn’t finish on time, or on new projects that came up during the quarter. This is your provision as a manager in case you just couldn’t follow rule #4.
  6. Leave the last week (#13) open as “overflow + planning”. This last week leaves you time for reflection, planning, and last minute efforts to end the quarter well. This is when you can have team brainstorming sessions or even relax a bit and think about things to come.
  7. Leave two (usually non-contiguous) slots open for “infrastructure”. I used this trick to appease my CTO and engineering team. They got to choose what infrastructure projects they’d work on, so they knew in advance that they’d have enough time to take care of longstanding infrastructure issues. Sometimes the project triage would cause some argument, but it’s worth it.
  8. Remember to plan for holidays and vacations. This way you’ll have a realistic expectation of what you’ll be able to finish, even if it’s less than ideal.
  9. Consider market deadlines and business goals. If feature A needs to be complete before a conference in week #5, make sure to work on it at the beginning of the quarter.
  10. Once the quarter is planned out, write it up on a whiteboard so everyone can see it. The quarterly plan doesn’t change unless it’s absolutely necessary. Explain to your team that it’s important we stick to the plan and power through.

An example quarter

A little of everything, but still a lot is accomplished.

The results

The impact of planning correctly made a huge difference in productivity for us. Gone were the early Monday meetings trying to figure out what our weekly plans are (it’s written on the board). Gone also were long projects, stretching for week after week. Now, each project had to be done in one week (maybe two). This forced us to really think: what’s the simplest way this could be done? How can we do this in two weeks? Everyone knew that we had to ship, what we had to ship, and when.

Going to the board at the end of the week and crossing out a task with a big green marker was a highlight for everyone. More importantly, working under planning constraints forced us to stop and consider where the company is going. That by itself sometimes turns out to be the difference between a healthy, effective company and a struggling one.

--

--

Gilad Avidan
Designing the Obvious

Opinionated hacker with feelings. Co-founder of Smore, currently working on something new. Hopeless typographer, wannabe activist.