Across the country, in every accelerator, exec team meeting, advisor session, and board meeting, startups are asked the same question:
“But how will it scale?”
My answer: “Who cares?”
In Defense of the Plan, Part 2
I wrote recently about the need for long-term planning, even (perhaps especially) in an Agile development environment. I left you with a choice: plan or fail.
The fun part about writing on the internet is that you don’t really have to solve problems: you just have to point them out so that other people can agree with you that yes, there is a problem there, and someone should do something about it. I’m a problem-solver by nature, though, so I can’t just leave it at that. If I’m going to tell people they need to do something, then I’m constitutionally required to help them do it. So we’ve already covered why you need a plan for your product development. Let’s talk about how.
Let’s start with a few objections, because I never met a straw man I didn’t like (to poke holes in):
“I can’t tell you when we’ll have a whole feature set done because we’re using Scrum/Kanban/Lean Agile/some other Japanese-sounding development process.”
“I can’t plan because I don’t know how long it will take to build something six months from now.”
“I can’t create a release plan because I don’t want executives to see it and think that my team has committed to specific deliveries way out in the future, where all the uncertainty lies.”
Let’s take these in order…