How we start significantly shapes the success of an initiative and also determines how able we are to stop if it isn't delivering what is expected or required.
If you start something, you should know how, why, and when to stop it. What are the objectives and success criteria, and how much should you invest to meet them? If you set off with clarity and know how it sits within your overall strategy, the goals can be communicated. You don’t need to have all the answers (and you probably shouldn't) but establishing the initiative with a framework that individuals, teams, and the organisation can refer to creates something we can all measure against.
In my experience, one of the key challenges is being efficient about 'finding out'. We’re in the business of establishing if an idea will be viable. We can build it and find out that way, but that's typically an expensive approach due to the risk of failure. In agile development, we would seek to tackle the most challenging problems first – the unknowns – on the basis that, if we can deliver those, the whole solution is deliverable. In the world of product development, even more crucial is the need to establish that there are customers who will pay for the solution to their problem.
In some organisations, the cost of finding out is often inflated by the default size and shape of a development team. If the standard team is five (or maybe more) people, then the baseline cost is significantly greater than if you could use a team of two to attack the same problem. How big does a team need to be when you're in feasibility mode? The leaner it can be, while addressing the primary areas of risk, the higher your chances of success.
And what are those primary areas of risk?
- Usability (can people use it?)
- Feasibility (can we deliver it?)
- Value (how much will people pay for it?), and;
- Viability (does this work financially for our organisation?)