I started the Wazoku business over six years ago. There are many reasons why I picked this sector and this idea of the many I had down in my “little book of ideas” at the time, not least because I had to have a little book of ideas!

I believe that my road to starting the Wazoku business was in many ways pretty typical for a British entrepreneur. I took my time, built my confidence and my experience, I waited for the right time and the right idea. I have spoken at length in other forums and other sites about my experiences, tips and thoughts, so I don’t want to go back over too much of that. If you are interested to read any of those posts, my recent Minute Hack or Share Radio interview – Harnessing Ideas with Wazoku, give a good overview.

The Wazoku story itself though I think is of relevance to the audience on this site. We as a company practice many of the things that businesses want to hear about, and so rather than talking theory, I thought I would share some of the practices inside an innovative software business. In this first post I will take the start of the Wazoku journey, looking at the early design thinking approaches and the wider context to getting the business off the ground. A 6-month cycle from initial idea to first customer.

Getting started: knowing how, where and when to start is a challenge I hear time and time again from entrepreneurs and intrapreneurs alike. We are all busy. We all have other things to consider. We can’t all take the risk. And by the way I understand and empathise with all of that sentiment. It took me over 10 years longer than maybe it should have to take my own steps after all. So how did we get started at Wazoku? There were a few trigger events that all came together at the right time and place. In December 2010 I had just left Huddle, where I had been for the past few years as one of the very early founding team members. The day I left Huddle I made a promise to myself and a few others, that I was going to start a new business, but at that time I had no idea what that business would be. I had my little book of ideas however and so I started there. I decided to set a number of plates spinning to test these ideas out in a very agile way and set about meeting as many people from my trusted network as I could to test one (or sometimes more) of these ideas on. I was looking for true, honest, brutal feedback. Some ideas were quickly dead in the water, some were not for that time, some too small for me to take forward, but a few plates kept on spinning.

Timing: one of the people I met up with at that time was my now co-founder James King from FIG.vc. This is where timing comes in to play. In talking through some of my ideas, James started talking to me about something that was a pain point for him and the team at FIG. The stars were aligning. His pain point and idea to resolve it was very similar to one of my ideas and we sat and started to draw out this idea into something more tangible and thought out. We spent about 6 weeks meeting regularly, testing the idea, sketching out mind maps, challenging each other, bringing in other people to the process to challenge and help us when we got stuck or too carried away. We managed to get from first conversation to a plan we could market and test within 6 weeks.

Keep the customer in mind: once we had a basic idea we set about building an MVP to get into the hands of potential customers as quickly as possible. Anyone who has tried building anything, the concept always sounds great, but it’s not until you get the idea into a form you can let people test, that you actually learn anything. We had a good network of business contacts (and of course FIG themselves) with who we could run user testing on the very basic ‘product’. We learned a lot in those early sessions that continue to shape the way we work today. We were also able to manage the number of dead ends and blind alleys we took ourselves down through false assumptions or bad implementation of our ideas. Working closely with the potential future customer was a vital step. However, it wasn’t a sole determinant of the direction we took with the product. After all, we were building this for scale, not one customer, we were building it with a bigger vision in mind also, it was going to be much more than this simple MVP…. assuming that we could get it off the ground.

Find your beta: I have seen too many entrepreneurs who are took afraid to push the button and send their product live, no matter how imperfect (or beta) it may be. I recognise there is a risk and certainly there are also examples of people being overly bold and launching into beta too soon. However, I would argue that was a poor definition of beta rather than the approach being flawed. It is vital to find your beta and get it out in the hands of real users. The earlier step of ‘user testing’ is of value, but there is no greater test than winning your first true customer, not a friend or someone with a vested interest, but a true, first customer who just loves the sound of what you are doing and is willing to ‘buy/try/use’ the product with no inducement or other reason for doing so. Every single product, business, service in the world started with a first customer. And without fail, they were all flawed in some way when launched. In the software-as-a-service world this should be standard practice with regular and frequent updates and fixes being push out in line with the data and user feedback.

Work agile (it helps you to learn fast too!): I think that fail fast is all well and good, but I’m not sure it’s as much a truism as we would like to pretend. It is too idealistic to think we are all going to keep failing (faster and faster) and everyone is going to be ok with it and keep rewarding us to fail more. I would far rather we learned fast, acted fast when things are going different to the plan, adapt fast and change direction if we have the data to suggest the current path isn’t taking us where we want(ed) to go etc. So, I propose we keep an agile soul and work to short, sharp defined sprints across the business, breaking down our larger projects into more bite-sized pieces and continually testing our assumptions and allowing for an informed degree of flexibility. The Agile movement seeks alternatives to traditional project management. Agile approaches help teams respond to unpredictability through incremental, iterative work cadences and empirical feedback. This, of course, gets harder to do as your business grows, but not impossible and no less important a capability to hold on to. I will share some thoughts on the best approach to staying agile or rediscovering your agile soul in a subsequent post.

These approaches were (and still are) all important to the early stages of getting Wazoku off the ground as a business and Idea Spotlight, our core product, from a set of ideas on a page to a hugely successful product on a global scale. In my next post, I will build on this and talk about the innovation pillars we work to at Wazoku, our everyday approach to innovation and how we continue to maintain and develop our agile heart and soul. Please do share any thoughts or comments on any of the above, or if you want me to explain any of this further add your comments and I will reply with more detail.