You Shouldn’t Scrap Business Plans—Just Make Better Ones
No, I am not here to offer a magic business plan. The case in point for discussion is whether a business plan is necessary, and if so, what is the right level of detail to go into?
An increasing number of articles currently advocate against the use of business plans. They want entrepreneurs to roll up their sleeves and get their hands dirty at the very start, whether it is building prototypes or talking to potential customers, all with the goal of monetization as quickly as possible.
These articles argue that creating a business plan is a waste of time; some even say it is irrelevant, as most successful businesses end up doing very different things from what they had originally outlined in their plans.
One may question if all this discussion is more prominent now due to the more widespread use of agile methodologies, which focus more on end-users and teams and place less emphasis on documentation. To counter this thought, there are several valuable articles that talk about the need of a business plan whether one operates in an agile or waterfall development methodology.
The core sections of a business plan define the vision, funding plan, and customer acquisition model, and these ideas are still very important. The issue that organizations sometimes have is getting into too much detail on these core sections.
Having been in the IT services business for more than eleven years, I can understand people arguing for and against business plans. For example, consider a scenario where a business plan is not defined and the business just works to quickly get a prototype out into the market. There are two potential issues here. Firstly, this may work fine initially, but very soon scalability could become a problem. In the absence of a plan, what is in the minds of a few entrepreneurs initially may not always be clearly passed on to the rest in the organization as it grows in scale. Secondly, people may rush into the monetization angle without clearly mapping their product’s implementation into measurable metrics around requirements and quality. A business plan certainly serves as a check to mitigate these two challenges.
Granted, an elaborate business plan can soon become obsolete and may not be a document that everyone will read and comprehend in entirety. However, the right business plan will be one that focuses on product vision, core idea, target market, and funding, and will keep all these details to the bare essentials. Rather than becoming pages of documentation that are not of much value to any stakeholders, a plan like this serves as an enabler to empower the team to build the best possible product.
