Please note that this blog is archived and outdated. For the most current information click here!

Agile Development: When to Pivot vs Iterate

The concept of iterating won't be new to anyone who has been reading this blog. Nor will it be new to anyone who has worked within an agile methodology before.

What is an iteration

Essentially, an iteration is a small change to a product, service or business which allows for value to be added within a quick timeframe. At WorkingMouse, we use the concept of iterations to goalpost our development. This breaks up the work to be done into smaller pieces.

Each iteration is tested and checked before and after development, to ensure that the focus of the iteration meets the needs of the users and the market. Usually, research conducted during scope, along with consistent testing during development and after launch, will ensure that these iterative tweaks are enough to keep a product or service on track.

Sometimes, however, there are situations in which things have gone awry, and an iteration is not sufficient to course correct. In those situations, there are two ways of handling it: pressing on ahead into the howling dark, hoping that things will fix itself, or a complete pivot.

What is a pivot?

A pivot is a complete change to the product or service offering and may even involve a change to the underlying business model.

A pivot can occur at any stage of the product lifecycle: during scope, during development or even post-launch. Sometimes, a pivot is necessary to save a product. In other instances, it may be a way to capitalise on changes to the market. Regardless of the reason, it's helpful to understand when it's appropriate to iterate and when it's time to pivot.

When to iterate

Iterations are the bread-and-butter of creating, launching and maintaining a product or service. Testing should be happening on a fairly regular basis in order to ensure that whatever is out to market is actually responding to the attitudes and needs of the users.

There are a few ways this testing can be carried out: analytics, user interviews, prototyping or ongoing market research, to name a few. Either way, a product owner can expect to iterate at least several times a year in order to keep their offering fresh. Iterations do not need to be major changes. Simple modifications, such as changing a font to make it more accessible, or tweaking an app's existing navigation, can make a huge difference to the user.

When user testing reveals opportunities to create value for users with relatively minor work, this would likely indicate that an iteration of some sort would be beneficial. Ideally for products which have already launched, iterations should be low-risk enough that they don't disrupt existing users, but provide enough value to justify the cost of development. In basic terms, iterative work is about staying nimble and ahead of the market by maintaining and improving a product in short bursts.

When to pivot

Iterations are fairly straightforward procedures, but pivots are much tougher undertakings. In general, pivots tend to happen when the core idea of a product or service has been undermined in some way. For example, user testing over a period of time may have revealed waning interest in the product's unique value proposition or UVP. When iterative approaches to better appeal or diversify the user base have failed, then the UVP itself will need to be changed. This is a major modification that will have consequences for the user experience, user interface and likely the functionality underneath. Unlike with an iteration, a scope is preferred for pivots. This is to allow for the problem to be fully understood before starting the agile development process.

Another reason why a pivot might be required is a lack of revenue or the costs of maintaining the existing application. In these instances, a pivot may involve changing functionality or access to make it easier for product owners to monetise their application.

Finally, another key factor that may lead to a pivot is core issues with the application related to UX or functionality that make it a difficult sell in a competitive market. At WorkingMouse we most often see this third scenario play out with projects that require a rescue operation - they have launched an application through another development house but the application in question has not been able to gain any traction. In cases such as these, a pivot might be the only way to save the venture.

What you might notice from the pivot examples I've listed above is that they will all require thorough scoping in order to succeed. In many ways, a pivot means starting a project from scratch. This means that all of the work associated with initiating a project - market research, sketches, user flow diagrams and prototyping - must be carried out again, in full. Iterations, being simpler, do not usually require much, if any scoping. Often, any scope work that is involved with iterations is limited to very rapid prototyping and simple discussions or white boarding sessions.

Regardless of whether your offering requires iterating or pivoting, hopefully by now you will see the value in keeping your application nimble and responsive to changes in the market. Being aware of the potential pitfalls of ongoing developing will ensure that your product remains proactive instead of reactive. This will, in turn, help your product provide a steady stream of revenue long-term.