When approaching a new business idea there is always a lot of uncertainty, you think of things such as:
- Will the idea work?
- what will I need to do to get it working right?
- What are the risks that will cause it to fail?
This can seem like a daunting task. You may just be put off it and avoid it and do something else instead easier instead. Or you might get distracted in the minutiae and never end up building the grand vision that you had for it.
This is a situation that I’ve been in many times.
Sometimes I have successfully scaled the mountain to execution and success. Other times I haven’t even made it past the first few steps, or I’ve slipped down after trying a few routes.
Why is Perfectionism bad?
One of the main reasons that I fail is perfectionism. I want to get my solution perfect before I even bother trying to launch it to customers. However, this approach is the opposite to newer more agile lean startup methodologies, this way is hard and prone to failure.
A more successful approach that I’ve learned is to be happy with an imperfect solution and to cut corners so that you to get further up the launch cycle quicker.
This approach has a number of benefits, but the key one is around feedback.
Real live feedback from your customers has a very powerful effect.
- it can give you a lot of motivation and focus to keep going,
- It can also make you feel sad because in the cold light of day no one was interested in using your product or service.
This latter scenario tends to be more common than everyone loving what you’ve done and having instant success.
You have to treat every failure or rejection as a minor victory.
Every time you interact with your customers you’re gaining more information about your venture. So each time you launch or get feedback to sift through all the data with a fine-toothed comb and see what nuggets of insight you can glean from it.
You may need to do a lot of sifting, or there may be no obvious insights.
But even that is an insight in itself and stops you wasting time and effort working on something that wouldn’t have actually gone anywhere.
Even if it is a failure, you will have learned a lot of valuable lessons. Because of this, you will be more likely to have success on your next idea – where you won’t make the same mistakes you made this time… Next time you’ll make different mistakes…
Each failure will bring you one step closer to success.
Fear of failure
A common problem is that people become so afraid of rejection in this situation. They wrap up their self-worth or view their project as a reflection of their abilities as a business person.
Instead of treating the whole thing as a mechanism for gathering information and insight. The more information and insight you have that you have gleaned with your own hands – the clearer you can see the landscape and the chances of your project being successful.
Now you may say that you’ve heard all of this before. To some extent you probably have – as I mentioned it is the classic agile approach to tackling a problem.
But the difference is that I’m not just talking about a piece of functionality, I’m talking about a process of mapping out what you don’t know, what you do know and leaving a space for the unknown.
Unknowns are what you want to find out. The only way to do it is by playing a metaphorical game of minesweeper with your product or service. Have a bunch of ideas/statements that you want to verify and try to verify them as efficiently as possible.
Sometimes the answers will be ambiguous and not give you any clear indication one way or the other… In a lot of ways that is the worst outcome because it leaves in you pretty much where you started.
A clear idea of success and failure
Always try and avoid that pitfall by setting out your tests/implementations in such a way that you’ll have a clearer idea of success and failure, leaving no space for a middle ground.
It is also worth using probability when possible and makes sure your success or failure is realistic or whether it was just a quirk of the way you ran your experiment.
To wrap it up
In one perspective, when building new businesses/trying new ideas we are revising our understanding of how the world really works – based on our intuition about what we think will work.
Instead of blindly stumbling around, I’m suggesting approaching the whole thing with a more rational, logical mindset that will increase the chances of success, and just as important the chances of progress and you actually want to continue with your idea.
The Biggest Challenge
One of the big challenges with any business is what needs to be done before you can tell if you have a successful business or not. It’s so easy to get distracted in building the business that you lose sight of the key thing:
Are there people around that actually want to buy what you’re trying to sell them?
By the time you do finally realise that no one wants to buy your product, it’s too late – you’ve already sunk in thousands of pounds and hours of your life.
As an example, for a relatively simple online app you need to:
- Buy a domain
- Design the logo
- Design the website
- Design the flow and actions that your website would take
- Figure out a pricing model
- Figure out the marketing
You would also need to hire a web developer to do all the work for you, as well as a designer to put the flows together.
Once you have done all this, you feel like you have accomplished something – you feel like an entrepreneur. But hold on a second. Something’s wrong.
The only people that have used your website are your mum and your best friend.
That’s ok, you think. People will find it
“I’ll post it on Facebook and it will go viral.”
“I’ll post a few links on twitter and everyone will think its amazing.”
But this never happens …you might get one visitor.
The next step is to look at the offering on the website. So you read loads of marketing blogs and decide you need a landing page with loads of key offerings. Or you might even conclude that the product is immature or buggy, so you go back and waste another month building even more features, making the list of things you offer even longer.
Eventually, you somehow manage to get three or four people using it; or you get feedback from some ‘expert’, leading you to fall into another loop of coding and tweaking. Convincing yourself that your gut is telling you that you need to make even more changes to the product.
Six months go by. You’ve built more, but now you’re losing your enthusiasm for the product. Finally, it seems you’re getting a clearer idea from people about it. The feedback is that it’s a cool feature but no one actually wants to pay a lot of money to use.
You tell yourself that it’s bad luck or its someone else’s fault, but deep down you realise, what you thought your customer wanted and what they actually wanted were two different things. Maybe if you had found this out earlier you wouldn’t have spent so long building it and spent the time doing another project instead.
So, how do you avoid this situation?
I don’t have the definitive answers but I believe that you should focus ruthlessly on what the customer wants and what they are actually willing to spend money on! There can actually be quite a big gap between these two things.
When people see an excited, enthusiastic person asking leading questions, they subconsciously want to make you happy. They don’t want to disappoint you, so they end up tell you what you want to hear – in the end, no one is happy.
Where possible, use more anonymous surveys where the people have no vested interest in helping you. Do your research by checking out social media, forums and Google trends to see if people are searching/asking questions about your solution.
In an ideal world, people are already looking to pay for your imaginary product before you’ve written too many lines of code.
Keep asking your audience and iterating to suit until you find something that you can sell.
That’s when the next set of challenges begin. Your value proposition and how you sell your item is almost as tricky as figuring out the application in the first place.
Nowadays there are a lot of engineers who just start building stuff because of a hunch, but I think if engineers learned more about how business works instead of spending all their time on development, they would have a better chance at succeeding.
A useful skill
Selling is something I have to do all the time. I regularly need to hone the essence of my pitch and figure out which core idea would resonate most with my prospective customer.
Even if you’re trying to save the world by changing the way people think about something or behave, this has to be rooted in a core idea that changes the person you are targetting.
I think the most powerful ideas have the ability to change someone
…and if you harness this process then you have the ability to change the world.
First of all, a good idea has to be a combination of facts and emotions. There are a lot of cold hard facts out there that you can tell someone that should change them but don’t. One of my favourites is:
This is an idea based in fact. It is written on the side of many cigarette boxes and maybe continually seeing this message does lead people to change, but it doesn’t happen in an instant. I think some ideas have the power to do that.
However, ideas based on emotion rather than fact, such as ‘get rich quick’ or ‘lose weight fast’, seem to compel us to want to change something quicker. I think this partly comes down to the perceived benefit of a new idea.
Most of the time when we sell we’re trying to convince the customer how our product/service will make them better or save them money, but they hear this so often from all angles that it’s hard to get through all the noise. You have to somehow capture their attention before you give them your idea.
In the past, I’ve struggled with public speaking. One of the ways I’ve tried to fix this is by joining a group called Toastmasters. Toastmasters is a membership group that uses a number of techniques to help each of its members improve their speaking abilities.
One of the areas of Toastmasters focuses on is how to present a compelling talk related to a given idea. The techniques rely heavily on repetition and a predictable structure you can walk the audience through, which allows the audience to easily follow your train of thought.
One of the more interesting tips is this idea of a narrative. When telling someone a story it seems to capture their attention more than just telling them a bunch of facts – I wonder what the significance of this is? Why do we respond to stories better than other forms of structured talks?
It’s also worth thinking about the film industry. All they do is sell stories – so why are some stories more effective than others? There is also a tried and tested formula for stories with a start, middle and end, this also goes by the name of the Hero’s journey. Further information can be found here.
Comedy is also a good area to look at when thinking about compelling ideas. Comedians rely heavily on this narrative to keep audiences rapt for an hour or two.
What other situations can you think of where you can comfortably sit for that long without getting bored?
Jokes rely heavily on a narrative structure, but also on the element of surprise. Traditionally split into two parts, the delivery and the punchline. What makes the joke funny is how big a surprise you provide and how wrong the audience’s assumptions were in the first part of the joke.
Mastering the process of capturing attention centres around finding a core truth and appealing on that deeper level. Fundamentally, people want to be rich, thin, better looking. They perceive that this will lead them to happiness. They must believe that once they have your widget they will be a better version of themselves than before.
Ultimately you’re trying to sell them happiness, but the way you sell them this varies.
Persuasion is also an interesting part of selling an idea. A lot of the underlying concepts around persuasion are about finding the core truths of a person so that you can tailor your idea to touch on their beliefs in a very targeted way.
In conclusion, I think some sort of narrative structure that strongly persuades the person that they will be happier, whether by having more money, more success or becoming more attractive, are the common themes when we are trying to sell to people. We have been doing this for thousands of years, but its good to take a step back and try and understand it better.
What works well and what doesn’t
I have been working in the software development industry for the best part of 15 years and worked in many different sectors across different industries. Through this experience, I have been involved in a variety of different types of teams, giving me a lot of examples of what works well and what doesn’t.
In this post, I will outline some of the observations that I’ve made and suggest the way forward for other teams.
Being part of an engineering team, writing software is a somewhat unique position to be in, as it’s a field that’s only existed for the last 20-30 years! Even though that time period, massive changes have also changed the landscape significantly.
- Computers are much smaller
- Smartphones are much more prevalent
- The introduction of the internet (which is faster and a lot more commonplace than when people first started writing code).
This is one of the key challenges with writing software; It’s such a relatively young discipline built upon shifting sands, so it’s hard to be as rigid with best practices, unlike for example, builders.
Second of all, the technology being built is also very abstract which causes challenges in its own right. A certain amount of cognitive overhead is caused just to be able to represent the program within a programmers’ head.
For example, if a builder is building a house there are plans and there is a building in front of them, you have bricks, cement and you have something that you can see which is tangible.
With software, we don’t have this luxury of designing something we can see with our eyes. We try to use our imagination to visualise the functionality that a program should have, which is quite a complex undertaking.
One of the biggest problems with it being so abstract is that the customer and user can have totally different ideas on what a given piece of functionality should do! As such, the developer could get to the point of having built this metaphorical house without it actually being what the customer wanted!
Or just as bad, the customer not understanding the relative complexity of creating a piece of functionality, and then expecting the developer to be able to just ‘tweak’ it or ‘add it on at the end, not realising that this will have a massive effect on the stability and cost of the solution itself.
On the flip side, the customer may also get frustrated with estimates. This is one of the most challenging areas of software development that really deserves a whole book in itself! If you go to a mechanic you expect them to tell you how much effort will be required to fix a particular issue, but software developers simply don’t have enough information to be able to do this effectively.
Often the customer may have a lot of domain knowledge about a given system, but not a lot of systems knowledge. As a result, when a new system is being built they lack the knowledge to specify a proper set of requirements, which leads to challenges when the system is actually built.
What they thought they wanted isn’t actually what they wanted.
Agile marks itself as a way of addressing this by having rapid, small iterations of work with continual feedback, and there are definitely merits with this approach. But agile is no silver bullet and should be used with a great deal of care.
The main reason for this is hidden complexity, as I mentioned earlier; even a simple piece of software is quite complex and to totally understand all of its facets requires quite a lot of work on the part of the engineer:
- All the different components
- All the different external systems that it interacts with
- How to handle feedback from a user
- What happens when errors arise
The danger arises when people try to make estimates for a given piece of functionality on the assumption that they have all the key knowledge to hand. However, they usually don’t have the knowledge which leads us into this situation where things overrun.
The problem is shallow system knowledge …or even if one person has it – it’s not being disseminated across the team effectively enough.
One key reason behind this is that engineers do tend to move between projects (and even companies) quite frequently, so this ends up in a very fragmented understanding of the system. People end up making changes without knowing all the implications.
There are a lot of challenges with software development around complexity, specifically. Many tools and processes have arisen in an attempt to mitigate these problems, but I think we need a big shakeup in the way that this is done.
We need to take a fresh look at delivering software within an organisation and see what could be improved.
Black box thinking and feedback loops
I read a very interesting book called Black Box Thinking. It essentially delves into the concept of feedback loops and how they can help individuals and organisations in a variety of different situations.
That aspect of the book was interesting, but the part that really stirred my imagination was around organisations/industries where Block Box Thinking was more evident and how negatively these industries were being affected by not having adequate feedback loops in place.
The industry that was held as a paragon of Black Box Thinking was the airline industry, and the way the black box is used, which is also where the book gets its name from. When something goes wrong the black box is consulted and there is a lot of transparency in place to make sure that even when people admit to mistakes they realise it’s for the greater good and so there is no comeback.
This has meant that the airline industry is one of the safest in the world especially considering how high risk it is.
Another industry closer to me where there is a lot of continuous feedback is agile software delivery. At the end of each sprint, we have a concept called a Retrospective, where we review what has gone well and what could be done better.
This leads to the team working more and more effectively as the sprints go on and delivering more value to the business.
However, I think it could be taken a step further, as there is still a certain amount of politics involved. People don’t always say exactly what they want, as they don’t want to hurt the other persons feelings or look to be a troublemaker. In this situation, I think anonymising the retrospective could help to raise deeper more challenging issues as there will be less fear of reprisal.
This concept of politics and reprisals is one of the biggest challenges with trying to apply black box thinking to industries that are in dire need of feedback mechanisms and more transparency in general.
If there is no clear feedback between a decision and its outcome then a lot of negative things happen – people can’t learn from their mistakes and there is no scope for improvement.
An example would be the medical industry, where mistakes are often covered up and a level of defensiveness happens when there is an error in surgery. If there was more transparency some of the deep underlying issues could be addressed and a lot of lives that are unnecessarily being lost could be saved.
So far I have given examples of industries where feedback loops have been useful or could be useful – but now I’ll talk about personal feedback loops and how they can help.
Weight loss is one of my favourite subjects and an area where a clear feedback loop can be placed. Weighing yourself regularly on a scale is a good example, as it can give you constant feedback on how your lifestyle choices are negatively or positively affecting your health with a discrete specific measurement.
This can be a powerful motivator to get you to make better choices. The quantified self also feeds into this if there were other health markers that we could easily measure then that would also help motivate us to be healthier.
One example could be blood sugar levels and insulin sensitivity – if we eat a lot of sugary food then our insulin sensitivity goes down but eating healthier and eating less sugary food could be a good way of combating that.
This would be even more specific than weighing yourself as that can be misleading, as sometimes you could be putting muscle on. With all these things you know that eating a bar of chocolate could be bad for you but if you could be more concrete in the way you quantify this then that spurs you on to make better decisions.
It is also possible to overdo it with feedback loops or to look at the wrong information which leads you down the wrong path for a particular thing.
In business: It could be looking at total revenue or hits instead of looking at conversions or profit. You could think you’re doing the right thing but in reality, you aren’t and it may be doing more harm than good.
Hopefully, I’ve given some compelling arguments into trying to incorporate feedback loops more into your business and daily life. They can be a powerful way to motivate and to focus your thoughts. Part of the reason why they work is that you move from being in a qualitative mindset to a more quantitative mindset, which helps you move past your biases and bad habits.