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.
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.
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 through 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. We try to list 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 – its 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 attempt to mitigate these problems, but I think we need a big shake up 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.
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 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.
Today I Want To Talk About Failure
Many people talk about success or talk about a failure within the context of later success, but sometimes failure just happens without leading to success down the line.
Some people are doomed to keep repeating the same mistakes again and again, or make a big mistake once and then be too scared to ever try again.
In this post, I will provide further information about the points made around failure above and discuss solutions or approaches to take when thinking about failure. But first I will talk about times that I have failed personally.
There are a number of times I have failed at things in my life. Some of those failures are small, some of them are big and have had a lasting impact on my life and how I approach things.
But paradoxically some of the bigger failures didn’t affect me as much as some of the smaller ones.
Failures in relationships come back and haunt us quite often as well. Primarily failures in romantic relationships, but also when friendships fail.
One of the biggest things about failure is the fear that it can cause – the way that fear manifests how we tackle new challenges, and sometimes the surprising subconscious defence mechanisms our brains put in place to help try and protect us from that failure.
An example would be: Starting a new business.
People love the idea of starting a new business and maybe have even built a small prototype or website. That part is easy. The scary part is when you actually come to the point of getting feedback from real life customers.
People make excuses for why they aren’t actively selling their product – it needs improving, something needs tweaking, but in reality, the main reason is that they don’t want someone to tell them that what they’ve done so far isn’t good enough.
They put too much of their personal self-worth into the product, so it hurts them more than it should when the product isn’t getting the traction or feedback that they want. Or there is a sunk cost fallacy whereby they have invested so much time and effort to get to that point that they feel that they can’t easily walk away, as it would all have been a waste of time, energy and money.
I have personally faced these issues and have had failures relating to this.
The way I was able to handle this is because having been through the failures; I realised it’s not as bad as you think it will be. You develop a certain mental fortitude that immunises you against such failures going forward. Fundamentally it’s all a state of mind – failure can be a good thing! It’s better to get a resounding no than an ambiguous maybe, as that allows you to stop going down a dead end and explore more fruitful avenues.
As a result, I do two things:
- I actively seek feedback from customers as soon as I can about a particular product or value proposition, as early as possible so that I’m not as emotionally invested in the outcome as I would be later on down the line.
- I treat each iteration as an experiment. This means that each step I take isn’t about failure or success its about learning something.
If you frame each step as a process of knowledge acquisition, then every step is successful by default. Mentally this takes a lot of pressure off you and whatever the outcome of your experiment you’re able to feel good about it as you know a little more about your business model or customer than you did before.
The key is to set up this feedback loop and make sure you are actively learning from your mistakes or that you have clearly stated the hypotheses that you are testing, otherwise you will end up repeating the same mistakes over and over again.
However sometimes there is nothing to learn from a venture or particular step, sometimes it can just be bad luck.
This has happened to me in the past – I tried to use my intelligence and experience to overcome a problem, but unfortunately, there were a number of factors that were stacked against me.
This kind of scenario can be very demoralising. So what do you do here? There is no easy answer – for me, I take solace in the analogy of poker. There is a lot of luck involved in poker, sometimes you can have the best hand and still lose, understandably this can be very frustrating.
However, the more seasoned players know that the luck always averages out so there’s no point in getting too caught up in emotions when your going through a purple patch.
I try and adopt the same approach in life and when I have ‘bad luck’ I remind myself of all the times I have had ‘good luck’ and just have faith that I’m learning from each mistake and keep going forward!