If you want to develop a tech product, you will undoubtedly have read or been told that you should use agile development.  There are many articles written about agile development, but they do not necessarily address the need to have an agile mindset.

By having an agile mindset, you will be able to more rapidly adapt to an ever-changing landscape.

Agile Development

Before agile development became mainstream, software followed a strict waterfall process, whereby one stage in the development process would not take place until the previous process had been successfully completed.  Whilst this ensured a highly engineered end product, the time taken to get to market was so long that the requirements had often changed before the software was deployed for use.

In 2001, 17 leaders in the field of software development got together to address the problems being faced by the industry with waterfall delivery.  They looked for a way of developing softare that would be fast, effective and in time (as opposed to on time).

The result was the Agile Manifesto which stated, at its core, 4 key values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This formed the basis of Agile Development.

It is fair to say that the principals and thinking behind the Agile Manifesto had actually been discussed for many years earlier but the creation of these 4 values ultimately led to a change in the industry, which is now recognised as the preferred way to develop software.

If you look at the 4 values, you will see that Agile Development is not a process but a set of preferences.  They form a set of ways of working that supersede the old, inflexible and slow waterfall processes.

The Need to be Agile

If you look back over recent history, you will realise how much and how quickly life has changed when it comes to tech products.  We have seen the rise of Uber, Netflix, Bitcoin, Minecraft and many more, revolutionary products.  All have been successful in disrupting their markets and changing the way we live our lives and all have done so very quickly.

There is now an expectation that products should be available now, not later.  

Agility Pre-launch

If you take your time in developing your product, you may find that once you get it to market, that the market has moved on or that you been beaten by a competitor.  You may also find that the product that you have so lovingly crafted is not one your customers want any more.  Life may have passed your product by.

Another factor that can drive change in your product is the product itself.  Something I find amazing about developing a product is that, as you develop it, you learn more about it and that reshapes your thinking.  In turn, this results in changes to your product.  This is a virtuous cycle in which the product appears to gain a life of its own and it begins to evolve.

The movement of the market and the evolution of the product also come together to form opportunities that you may be able to leverage.

Whether it is due to market pressures or product evolution, you need to be prepared to act and make changes to your product.

Agility Post Launch

It is clear that there is a strong case for agility during the initial development of the product, but do not think that it ends once you launch.  To remain competitive your product must continuously and rapidly evolve.  

Following launch, it is recommended that you collaborate with your customers and seek feedback on your product.  You will be surprised at the amount and variety of feedback you can get.  I often say that customer feedback is like gold.  You should accept the feedback and act on it.  The downside is that you will need to continuously prioritise what you do next, especially when you have limited funds.

That prioritisation is not easy.  Some of that feedback will challenge your product, some of it will be misunderstanding, some will be suggested improvements and some will be defects.  The order in which they should be tacked may not be clear.

To make things more difficult, once you have decided what to do next, more feedback will arrive that will require you to change your priorities.

It seems that post launch requires just as much agility as pre-launch.

Agility as a Mindset

Whether it is the market is moving, the competitive landscape changing or the fact that you are starting to understand your product, you need to be able to quickly:

1. Recognise that a change is required and accept that fact.
2. React by identifying the opportunities the change affords.
3. Respond by altering what you are doing to address the change.

This recognise, react and respond cycle needs to be fast.  No procrastination, no self-doubt and no analysis paralysis.

Recognising and accepting the need for change is one thing I find teams can struggle with.  Even though they may verbally agree, inwardly they are defensive, trying to protect their creation and unwilling to change their ways. This self-justification can be within an individual or even across a team.

This resistance to change can lead to the change being dismissed.  It is classed as something that can be done later and that nothing needs to be done right now.  This is classic waterfall thinking.

“Let me finish what I am doing and then I will look at what needs to be done later”

More often than not, individuals and teams alike need to be encouraged to adopt a different way of thinking:

1. They need to recognise and accept the need for change.  They need to understand that this is part of life and not an exception to the rule.
2. They need to react positively to change, understanding that change brings about opportunity to enhance and advance.
3. They need to respond to change by being willing to adjust their thinking and updating their solution, even if this means reworking or undoing previous work.

With an agile mindset, you are not hindered by your original idea, work done or your short-term goals.

In days gone by people were asked to ‘think on your feet’ but now-a-days we refer to the need to be agile.

Go Fast, Fail Fast, Fix Fast 

So far, I have discussed the need to have an agile mindset to recognise, react and respond to a change from an external stimulus, such as customer feedback or market pressures.

Having an agile mindset goes further than this.

When developing your product, you must accept that it is ok to fail.  It is only through our failures that we learn most effectively and therefore your failures define the path to your ultimate success.

To be successful, however, you must not fall when you fail.  You must quickly analyse what happened, learn and move on.  You must do this as rapidly as possible.

Go Fast, Fail Fast, Fix Fast (and repeat)

To achieve this, your team must feel safe in their failures.  You must create an agile environment and a mindset that says it is ok to fail, so long as you learn, fix the problem and carry on without missing a beat.

The Fallacy of Chasing Perfection

We all want our product to be the Rolls-Royce of our product genre.  We want it to be sophisticated, fully featured, highly performant and highly valued from the day it is launched.

In fact, this is such a strong drive in many founder’s minds that they will put everything into the creation of this amazing, perfect product for launch day.  They will consume all their available resources to get there.

Many times I have seen the pursuit of perfection get in the way of progress and success.

Being Embarrassed

Part of this drive is the founder’s belief that there is only one chance to get it right.  They cannot afford to be embarrassed.  They are worried that they will be slaughtered in the court of social media.

The founder of LinkedIn, Reid Hoffman is often quoted as saying:

“If you are not embarrassed by the first version of your product, you’ve launched too late”

To me this doesn’t give me permission to go to market with a flaky, low-quality product, but that you should accept that, if you are trying to achieve that Rolls-Royce product from the outset, you will be too late, and, will most likely be embarrassed anyway.

It says:

1. Put the fear of embarrassment aside as it is likely to happen anyway
2. Look at what you can achieve that would be classed as a Minimum, Viable Product (MVP), by your customers
3. Build the best quality MVP you can with the time and resources you have
4. Launch it
5. Now enter a cycle of never-ending improvement

This reflects an agile mindset.  Be prepared to go with what you have got, recognise the feedback from the customer, react by exploring the opportunities of the change, respond by building the next version of your product.

This is a virtuous cycle that should be followed as rapidly as you can.

Striking a Balance

So, does this advice say that you should flap in the wind like a kite in a hurricane?  No.  When you decide to react to a change, you need to keep an eye on your end goals.  

There will be times when the feedback from customers may be requesting changes that are not going to serve your longer-term ambitions.  For example, they may be asking you to turn your accommodation booking application into a stock market application.  This is far off-course and could not even be classed as a pivot.

But how far is off-course?  If the feedback says that you should incorporate long-range weather forecasts into your application, then it may be something to be considered.  If the feedback says that it should become a transport booking application, it may be worth the pivot.

When applying an agile mindset, your original vision, goals and values should act as a beacon in the distance.  Sure, you can adjust course, left and right, but you should always be heading towards that beacon.

I have seen cases where chasing the latest opportunity has caused products to become lost and wandering without gaining traction.  If you want to change the position of the beacon and pivot, that is ok, but do so carefully, consciously, deliberately and rarely.

It is better to be good at one thing than mediocre in a lot of things.