On the importance of not trying to eat the whole Elephant at once

Background

The great beauty of writing these blogs is it gives you the opportunity to read a whole load of background material to support the ideas you are trying to put across.

I’ve been using the elephant eating scenario for a while now but I had no idea I was quoting Archbishop Desmond Tutu.

I just though it was a random expression that someone thought up for a seminar one day.

Anyway; to quote Archbishop Desmond Tutu.

“there is only one way to eat an elephant: a bite at a time”

It does make more sense when you know where the quote comes from.

Why am I using such a random expression here ?

We do a lot of work with people looking to build new websites for their businesses via our involvement with Snook Digital.

Web development is about merging the frameworks we use to create websites with the words and images that our clients craft.

We tell all our clients that whilst we can create the basic site in weeks the limiting factor will always be how fast they can create words and pictures. We need them to tell us all about their product … we aren’t telepathic.

A lot of businesses come to us with a grand plan to build everything and not to release anything into the wild until its completely finished.

They try to eat the whole elephant in one go and generally fail to deliver any content at all.

Most businesses have a relatively short attention span; business requirements change and the search for perfection means that things don’t get finished before that attention moves onto the next bright and shinny thing.

We sink time and energy into projects that ultimately end up gathering dust. It becomes another great unfinished work.

Breaking things into bite sized morsels

Agile Software development originated in the early 2000’s as a way to deal with the growing recognition that a significant proportion of software developed was never actually used. As I have outlined above by the time this software was perfected the business process it was designed for had moved on.

Even today according to ZDnet;

“success in 68 percent of technology projects is "improbable". Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start.”

Agile methodologies are about breaking the elephant up into those bite sized morsels that are easier to digest and more importantly can be completed in a relatively short timescale within a businesses attention span. Software developers have introduced a whole new range of terminology to get away from the old way of doing things; everything from product owners, through burn down charts and story points to sprints.

The concept of product backlogs and sprints evolved as part of this process of breaking thinks into smaller chunks.

Product backlogs are about building a list of useful things to do, prioritise the list, building the bits at the top of the list; putting them out into the working environment before the business loses interest and repeating the process. The simplicity of the approach proved to be a big hit.

There is more to Agile Development than this but the basic principle works and Agile methodologies have found there way into a huge number of businesses over the last 20 years.

Scrum, (the image isn’t completely random), is one of the more popular Agile methodologies.

The bare necessities

One of the other buzz phrases that evolved around the same time as Agile was the Minimum Viable Product or MVP.

Minimum viable product is about working out what is the simplest (and therefore easiest) version of a product to create that is actually going to be useful to people. The problem with agile development is how to get to something that is useful to people in the first place.

The MVP looks to minimise the initial development time, cost and risk associated with a new product.

By building the simplest form of the product our customers will find useful and therefore buy we shorten the time between the light bulb moment and us making money from the concept (or working out that we are deluding ourselves.)

Obviously that doesn’t work well if you are talking about diesel powered attack submarines or large double deck airliners but for your every day website it works well.

Conclusion

Coming back to the elephant in the room and our clients.

So now we are unashamedly asking our clients … do you really need that page on your website from day one ?

We can reduce the content to what’s really important to the customers customer.

This is particularly effective where our more service/consultancy orientated clients are concerned. The website is a point of reference.

People are looking to understand;

a) they are dealing with a reputable organisation.

b) which member of the consultancy they talked to at the trade show; we all like a photo of the management team and a bit of biography - not forgetting the office dog.

c) at a high level what products are available generally from the company.

d) how to make contact….. and we all need to make sure this works -> the quick way to turn away a customer is to have a digit wrong in the office phone number..

Potential customers don’t need the entire list of case studies back to 1986.

Its all about the call to action - you actually want them to phone you to hear more so that you can start to build a relationship. Selling stuff is all about the know, like and trust.

We also emphasise that a website is for life not just Christmas.

You have to keep feeding it content to keep it relevant and more importantly search engines like websites that are being updated on a regular basis. This requires a series of increments which works well with the Agile/iterative/MVP idea and where users are being driven to a website from social media.

So the question you need to be asking yourself is how fast is your website going to be generating revenue for your business and how will you know how effective it is….. but that’s a subject for another day.

Bill/August 2021