Few business plans get it right first time with nearly nine out of ten business start-ups and one in six business transformations failing. Why is this? Is it due to inadequate planning, poor execution, or perhaps it is simply the cost of doing business? Sadly, it’s usually because the business plan is the first idea we came up with.
Finding a Business Plan that Works
The business plan is widely accepted as the starting point for most major business ventures including new ventures, new services, or major business transformations. In fact, any place with a high enough degree of risk and uncertainty to warrant a business plan.
So how do you get the business plan right? The answer is to introduce a period of discovery. This way, you get to iterate through a lot of different business plans until you find one that does work.
What does Business Plan Discovery Look Like
Well, it doesn’t look like a whole lot more analysis. Business plans cannot be validated through analysis. Instead, teams must interact directly with their customers from day one, according to the following principles:
- Get out of the building: Don’t guess what your customers want, ask them.
- Keep prototypes minimal: Prototypes are used to validate assumptions. They should have only those features needed to prove a point.
- Fail quickly: Iterations should be fast to maintain momentum and learn as much as possible.
- Find out Why, not What: Most important of all is to learn why customers need the product, this enables you to anticipate change and not just react to it
How does this apply to large internal projects?
By Large Internal Project, I mean something transformational enough to change the way the business operates. Say a core systems replacement for a bank, or the adoption of a completely new operating model. These kind of projects usually have a business plan, some degree of change management, and a lot of analysis designed to predict what might work. They also fail big, and fail often.
So how could we adopt a customer development approach here? Here are some ideas:
- Define the problem to be solved. Amazing how often we jump straight into corporate solution and forget to check that there is in fact an underlying purpose
- Validate what people need and want. Complex change seems to work a whole lot better when those affected are actively engaged in shaping the solution. I don’t mean a simple survey, I mean active involvement and observation of what actually works. Give people a reason to change before expecting them to actually change anything
- Validate the delivery mechanism. Don’t just trust your suppliers, put them to the test. This includes internal suppliers to.
- Validate the ongoing cost mode. This includes maintenance and servicing once systems are in place, as well as training costs and any other operating costs. Will the change happen in isolation or will there be a follow on effect? Try it with a small prototype and find out.
This is a brief look at a pretty large area. I may come back to it over time. Feedback welcome.