Agile Software Startups: The Myth Of The Perfect Business Plan

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Agile Software Startups: The Myth Of The Perfect Business Plan

 

Lets say I had this idea for a great software product.  If I told you I was going to spend the next 3-4 months writing (and rewriting) the product specification and design documentation and do everything I could to address what I thought would be the key issues, and then expected to actually use that document to build a near-perfect product that was going to succeed in the market, you’d likely dismiss me as being naïve or inexperienced or both.

 

Why?  Because, clearly, if we’ve learned anything about software development it’s that the process is difficult to completely plan for and much of what actually happens has to be emergent and “iterative”.  Though you may not be a fanatic follower of any of the specific agile methods (like XP), chances are, you basically agree with some of the fundamentals of the movement.  Chances are, you wouldn’t develop a relatively sophisticated software product today without using some agile methods.  Chances are, you wouldn’t be blindly using the waterfall approach in its original form.  The most important agile principle (at least for me) is the need for iteration.  In an agile development world, we do not try and predict every possible situation our product will need to handle, but we iterate and improve and refine – with the help of users/customers.

 

So, why is that when it comes to starting businesses, so many of us otherwise experienced and savvy software developers fall into the “waterfall trap” and spend inordinate amounts of time writing and refining the business plan?  I would guess it’s because we think that a business plan is a necessary component for raising funding (from VCs, angels, etc.) and that funding is a necessary component for actually building the business.  As it turns out, this is not really true.  You can start a software business without raising funding, and you can raise funding without writing a business plan. 

 

Why not take some of the same ideas we’ve learned from agile software development and apply them to software startups?  Though I recognize that developing businesses and developing software are different in many ways (I’ve done both for longer than I care to admit), there is enough in common that its worth thinking about.  In this light, I humbly offer to you the agile startup manifesto with credit to the original.

 

The Agile Startup Manifesto

 

We, the entrepreneurial software developers of the world believe that we have uncovered better ways to launch and grow successful software businesses.

 

Through our experience, we have come to value:

 

  1. Useful software over a comprehensive business plan.  We would much rather focus on creating value – in the form of (somewhat) working software, than planning to create value in the form of a business plan.  

 

  1. Customer revenues over external funding.  Customer revenues are the clearest evidence that we are solving the right problem.  The sooner we figure this out, the better.  If we want to learn about what users might want in a software product, we ask the users.  If we want to learn what the market might or might not want in an offering, we ask the customers.  Customers communicate with their cash. 

 

  1. Responding to change over following a plan.  We realize that most software businesses (especially the ones that survive), rarely stick to their original idea.  Flexibility is key.  We realize that most of the information we need to succeed with our strategy will not become clear until after we launch the company and product.  Recognizing this, we focus on responding to change rather than stubbornly following our original plan.  The key is to iterate.

 

  1. Building It well over building to sell.  We have learned that the best software developers design and develop products that they are passionately committed to “getting right”.  Programming is an expression of the ideas of the developer which blends in real-world feedback from customers.  There is pride of authorship.  These are the software products that succeed.  Just like we wouldn’t develop a software product with the notion that we’ll simply be “passing it off” to someone else to maintain later, we don’t build businesses with the express intent of “flipping” them some day.  This leads to mediocre businesses that are at the whim of the market.  Instead, we design our companies much like we would design our software.  With an eye towards balancing the difficult tradeoffs, and building something that is designed to endure.  Like our software products, we would rather build it well.

 

I think that individuals and companies that use agile methods have a distinct advantage over those that don’t (and likely have a lower failure rate – though I can’t prove this).  I would similarly argue that applying agile principles to software startups would likely have a similar effect – a lower failure rate and better businesses that actually create real value and are sustainable.

 

If there are other ideas and concepts from software development that you think have parallels with software startups, please share them.  

Posted by on Fri, Apr 14, 2006

COMMENTS

As usual, I couldn't agree more with the vast majority and spirit of your post.

I still have a nit to pick with the "customers vote with their cash" point, which you also raised earlier in saying too many entrepreneurs give their product away in the early stages when they could be charging for it. Obviously you're right for many cases. But I do think there's something to be said for mind share, buzz, word-of-mouth type stuff that spreads more easily to more people when the service is free. I have to organize my thoughts on this topic and blog about it in more detail one day.

It's also fairly impressive how this blog is not regularly in the reddit hits ;)

posted on Friday, April 14, 2006 at 11:38 AM by Yoav Shapira


Also, s/impossible/difficult in "the process is difficult to completely plan for" above ;)

posted on Friday, April 14, 2006 at 11:39 AM by Yoav Shapira


I do indeed have a bias for cash (vs. other forms of customer value). Though, I do recognize that there are alternative models for value creation and other ways to get "signals" from the market.

Will plan to write about this as a follow-up to my prior article on giving software away for free. Now that I've had a chance to vent a bit, will take a more balanced (and thoughtful) view in the follow-up article.

posted on Friday, April 14, 2006 at 11:43 AM by


Maybe I'm misunderstanding but although the tite says 'agile' doesn't all that upfront reqs and design work seem tad more like 'waterfall''?

posted on Friday, April 14, 2006 at 1:05 PM by Keith


"You can start a software business without raising funding, and you can raise funding without writing a business plan"

Dharmesh: I agree with #1. How about #2-- do you personally know of any VC who would fund your company without seeing a business plan or better yet, would you fund my company without a business plan?

posted on Friday, April 14, 2006 at 1:14 PM by nikhil


On point #2 (raising money without a business plan), I would answer yes and yes to both questions.

Yes: I know of many companies that have been funded without a formal business plan.

Yes: I would fund a company (and have) that did not have a business plan.

When possible, investors would rather fund businesses (than business plans). The business plan is one "signal" that you have done some work and thought things through. But, show me a company with a product, some revenues and a vision, and the business plan is not meaningful.

posted on Friday, April 14, 2006 at 1:17 PM by


Put a different way - if you're going to run a small business to compete with the big boys, take advantage of being a small business! Agility, speed, customer service, making hay from the small-scale, low-cost methods that are not available to the big guys because the methods themselves are too small for the big guys to profitably exploit.

Pit your strength against weakness. That's now David - armed with a sling and dead aim - beat Goliath's club.

JC Levinson writes on this a lot - his Guerrilla Marketing books should be required reading for entrepreneurs.

posted on Friday, April 14, 2006 at 4:41 PM by Ray Deck


Great article...would love to see more ideas like this. They are really motivating and informative.

posted on Friday, April 14, 2006 at 5:13 PM by kk


What a great 'mashup' post. I've been running my businesses using many of the same agile ideas that I learned as a software developer. I can relate to these ideas very well.

posted on Saturday, April 15, 2006 at 8:00 AM by danny


I hadn't thought of this before. It's a good article.

The one tiny reservation is that I'd add a caveat that "being agile" isn't as important as "being successful". Too many developers-turned-entrepreneurs like to choose business opinions first and then force their efforts/company to fit the opinion. For example, many people tend to decide that they want/hate VCs first rather than looking at their company and business and THEN deciding that they want/hate VCs.

Maybe an additional thing could be: "We are open to all possibilities, then we narrow our choices based on facts, estimates and analysis."

posted on Monday, April 17, 2006 at 12:36 PM by Daniel Howard


Pleace sned to me the free businessplan models

posted on Wednesday, January 09, 2008 at 8:02 PM by Taina Puumalainen



Comments have been closed for this article.