It’s okay if you don’t know exactly where you’re going – because things are always changing – just so long as you’re focused on the Right Things. BUT, this is really hard at a startup precisely because everything is always changing. It’s essential that your developers are okay with these points. It drives me a little crazy every time I hear a startup developer complain that things are changing all the time. Well… what’d ya expect? BUT… in their defense, I’ve seen many a startup do a truly horrible job managing their developers so that every ounce of chaos comes flooding down on them to the point where they can’t get a thing done. This often plays out something like this.
The Ineffective Way to Build Your Startup’s Product
Founder: We need to get this “MVP” out the door to start bringing in revenue if we’re going to survive. How long will it take you to build this?
Dev: I can do it in 2 weeks.
Founder: Great, go for it.
Two days later…
Founder: I just spoke with some potential investors and they said we need to do X if we want to raise money. Do that instead. How long will it take you to do that?
Dev: Well, if I stop working on the MVP…
Founder: Yes, stop working on that – raising funds is the most important thing
Dev: Then… I can probably do X in 3-4 weeks.
Founder: Great, get to it.
The next week…
Founder: We found a company that’s willing to pay us money if we give them Y. Can you work on Y while you’re building X?
Dev: Sure, but it’s going to take more time if I have to work on both of them at the same time.
Founder: That’s fine, do it. We need both to survive.
Dev: *grumbling* okay…
3 weeks later:
Founder: I’m ready for X, where is it?
Dev: I’m not done with it yet because you asked me to spend time building Y as well.
Founder: Damn it. Why can’t you ever get anything done?
This is, of course, a ridiculously tame version, but… you get the idea. We’re now 1 month into our startup without a thing to show for it. This method is NOT effective.
Let’s try something else…
A Better Way: Kanban, MVPs & Slowing Down (kind of)
Rule #1: Keep tasks small enough to be completed within your minimum time between changes (MTBC)
If your startup needs to be able to change what’s being developed on a daily basis, then don’t give your developer 2 week long tasks. Instead, determine your minimum time between changes & keep tasks small enough to fit within that.
For an early stage startup, I’d recommend starting with an MTBC of 1 day.
In Kanban, we set up a simple task board with To Do, In Progress & Done columns.
In our To Do column, we put up some cards representing the tasks to be completed. Make sure that each of these tasks feels like it can be completed within our MTBC.
Rule #2: Limit the “To Do” column to a ridiculously small number of items
I’d recommend starting with a maximum of 5-10 tasks, or about 1-2 weeks of work.
Your Kanban board should be displayed largely and prominently for everyone to see. This keeps the team focused. It doesn’t mean you might not have a billion and 3 other things you’d love to do, but that can be confusing and – at a startup where things are constantly changing – can send developers spinning. So keep those other items in a spreadsheet or notebook for yourself. And keep the Big, Visible focus on what we need to be doing Right Now.
Rule #3: Once a person starts a task, it can’t change while they’re working on it and they must complete it before beginning the next.
This is Super Important as it allows the developer to get into a cadence of continually delivering value (no more “Why can’t you ever get anything done?”).
Occasionally you’ll find it was the wrong task or defined incorrectly but our tasks are tiny (e.g., 1 day) and I promise you the value of all the correct tasks that get completed will greatly outweigh the occasional wrong task that does.
Rule #4: Go only as fast as you can learn
It doesn’t help to build product at lightning speed if you’re never stopping to validate that you’re building the Right Thing. As Eric Ries says, this is like praising ourselves for driving at the proper speed with great gas mileage as we drive off a cliff.
I like Ash Maurya’s idea of inserting a Validated Learning column onto the board. You don’t actually count something as “Done” until you’ve validated whatever it is you were hoping to achieve with that feature.
I’d recommend defining how long you think you can afford to go between validating ideas. In an early stage startup, you probably want to keep this to 1-2 weeks at most. So incorporate this into your planning process. I’d recommend using Hypothesis-Driven Development:
- Figure out what the riskiest assumption is in your business model.
- Figure out how you can learn (validate) whether your assumption is true or not.
- Figure out what the smallest possible thing is that you can build in order to validate it.
- Break this down into tasks that are <= your MTBC & place them in your To Do column.
- Once the tasks are completed, take the time to learn whether your assumption was right or not.
- Use what you learned to determine what the most effective next thing will be for you to focus on developing
If you’re new to Kanban or want a little more info, check out Kanban is the New Scrum.
