Agile Development: When to Pivot vs Iterate

The con­cept of it­er­at­ing won’t be new to any­one who has been read­ing this blog. Nor will it be new to any­one who has worked within an ag­ile method­ol­ogy be­fore.

What is an it­er­a­tion

Essentially, an it­er­a­tion is a small change to a prod­uct, ser­vice or busi­ness which al­lows for value to be added within a quick time­frame. At WorkingMouse, we use the con­cept of it­er­a­tions to goal­post our de­vel­op­ment. This breaks up the work to be done into smaller pieces.

Each it­er­a­tion is tested and checked be­fore and af­ter de­vel­op­ment, to en­sure that the fo­cus of the it­er­a­tion meets the needs of the users and the mar­ket. Usually, re­search con­ducted dur­ing scope, along with con­sis­tent test­ing dur­ing de­vel­op­ment and af­ter launch, will en­sure that these it­er­a­tive tweaks are enough to keep a prod­uct or ser­vice on track.

Sometimes, how­ever, there are sit­u­a­tions in which things have gone awry, and an it­er­a­tion is not suf­fi­cient to course cor­rect. In those sit­u­a­tions, there are two ways of han­dling it: press­ing on ahead into the howl­ing dark, hop­ing that things will fix it­self, or a com­plete pivot.

What is a pivot?

A pivot is a com­plete change to the prod­uct or ser­vice of­fer­ing and may even in­volve a change to the un­der­ly­ing busi­ness model.

A pivot can oc­cur at any stage of the prod­uct life­cy­cle: dur­ing scope, dur­ing de­vel­op­ment or even post-launch. Sometimes, a pivot is nec­es­sary to save a prod­uct. In other in­stances, it may be a way to cap­i­talise on changes to the mar­ket. Regardless of the rea­son, it’s help­ful to un­der­stand when it’s ap­pro­pri­ate to it­er­ate and when it’s time to pivot.

When to it­er­ate

Iterations are the bread-and-but­ter of cre­at­ing, launch­ing and main­tain­ing a prod­uct or ser­vice. Testing should be hap­pen­ing on a fairly reg­u­lar ba­sis in or­der to en­sure that what­ever is out to mar­ket is ac­tu­ally re­spond­ing to the at­ti­tudes and needs of the users.

There are a few ways this test­ing can be car­ried out: an­a­lyt­ics, user in­ter­views, pro­to­typ­ing or on­go­ing mar­ket re­search, to name a few. Either way, a prod­uct owner can ex­pect to it­er­ate at least sev­eral times a year in or­der to keep their of­fer­ing fresh. Iterations do not need to be ma­jor changes. Simple mod­i­fi­ca­tions, such as chang­ing a font to make it more ac­ces­si­ble, or tweak­ing an ap­p’s ex­ist­ing nav­i­ga­tion, can make a huge dif­fer­ence to the user.

When user test­ing re­veals op­por­tu­ni­ties to cre­ate value for users with rel­a­tively mi­nor work, this would likely in­di­cate that an it­er­a­tion of some sort would be ben­e­fi­cial. Ideally for prod­ucts which have al­ready launched, it­er­a­tions should be low-risk enough that they don’t dis­rupt ex­ist­ing users, but pro­vide enough value to jus­tify the cost of de­vel­op­ment. In ba­sic terms, it­er­a­tive work is about stay­ing nim­ble and ahead of the mar­ket by main­tain­ing and im­prov­ing a prod­uct in short bursts.

When to pivot

Iterations are fairly straight­for­ward pro­ce­dures, but piv­ots are much tougher un­der­tak­ings. In gen­eral, piv­ots tend to hap­pen when the core idea of a prod­uct or ser­vice has been un­der­mined in some way. For ex­am­ple, user test­ing over a pe­riod of time may have re­vealed wan­ing in­ter­est in the pro­duc­t’s unique value propo­si­tion or UVP. When it­er­a­tive ap­proaches to bet­ter ap­peal or di­ver­sify the user base have failed, then the UVP it­self will need to be changed. This is a ma­jor mod­i­fi­ca­tion that will have con­se­quences for the user ex­pe­ri­ence, user in­ter­face and likely the func­tion­al­ity un­der­neath. Unlike with an it­er­a­tion, a scope is pre­ferred for piv­ots. This is to al­low for the prob­lem to be fully un­der­stood be­fore start­ing the ag­ile de­vel­op­ment process.

Another rea­son why a pivot might be re­quired is a lack of rev­enue or the costs of main­tain­ing the ex­ist­ing ap­pli­ca­tion. In these in­stances, a pivot may in­volve chang­ing func­tion­al­ity or ac­cess to make it eas­ier for prod­uct own­ers to mon­e­tise their ap­pli­ca­tion.

Finally, an­other key fac­tor that may lead to a pivot is core is­sues with the ap­pli­ca­tion re­lated to UX or func­tion­al­ity that make it a dif­fi­cult sell in a com­pet­i­tive mar­ket. At WorkingMouse we most of­ten see this third sce­nario play out with pro­jects that re­quire a res­cue op­er­a­tion - they have launched an ap­pli­ca­tion through an­other de­vel­op­ment house but the ap­pli­ca­tion in ques­tion has not been able to gain any trac­tion. In cases such as these, a pivot might be the only way to save the ven­ture.

What you might no­tice from the pivot ex­am­ples I’ve listed above is that they will all re­quire thor­ough scop­ing in or­der to suc­ceed. In many ways, a pivot means start­ing a pro­ject from scratch. This means that all of the work as­so­ci­ated with ini­ti­at­ing a pro­ject - mar­ket re­search, sketches, user flow di­a­grams and pro­to­typ­ing - must be car­ried out again, in full. Iterations, be­ing sim­pler, do not usu­ally re­quire much, if any scop­ing. Often, any scope work that is in­volved with it­er­a­tions is lim­ited to very rapid pro­to­typ­ing and sim­ple dis­cus­sions or white board­ing ses­sions.

Regardless of whether your of­fer­ing re­quires it­er­at­ing or piv­ot­ing, hope­fully by now you will see the value in keep­ing your ap­pli­ca­tion nim­ble and re­spon­sive to changes in the mar­ket. Being aware of the po­ten­tial pit­falls of on­go­ing de­vel­op­ing will en­sure that your prod­uct re­mains proac­tive in­stead of re­ac­tive. This will, in turn, help your prod­uct pro­vide a steady stream of rev­enue long-term.


Rhiannon Stevens

Creative sto­ry­teller and ex­pe­ri­ence ex­pert

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call