Agile Development 101

 One of the main benefits of the COVID crisis is the realization that set upon most of us that shifting to an agile world and decision-making style is far easier and more productive than we realized.  Decisions were sped up, particularly technology-related decisions, and processes stood up way before perfection.  The surprising result was customer approval and satisfaction, in lieu of the anticipated disappointment with the imperfect solutions we offered. 

CEOs throughout the system awakened to the fact that in many cases (not all), speed is more important than full functionality and other considerations.  PPP showed us what we can do through brawn and brain.  We are now integrating the lessons learned into our thinking.

What is Agile development, then?  What processes and expectations should we put in place to capture and continue the innovative spirit many of us adopted through this period?

My son-in-law Jake works at a unicorn company named Amplitude, i.e. a place that is still private, but implicit valuations exceed $1B.  Many of the processes he and his company employ are not applicable to our industry, but the thought process itself can and perhaps should be adopted in some of our businesses.  Below is the thought framework I learned from Jake.  I hope you will find it useful; I sure did.

1. There are four phases to any development:

a. Minimal – the absolute minimum requirements to even try a product, process or tool.

b. Viable – when is something we tested ready for market introduction?  It might not be completed, but it’s ready to start serving customers, even if partially.  

c. Complete – the stage at which the offering is complete and has penetrated the market fully.

d. Loveable – full customer penetration and delight.

2. For each phase there are two important types of considerations:  marketing elements and product elements.

3. Every step of the development process passes through these four phases.  Every business can and should define when a product, process or experience passes through each stage.  

For example:  the first question you ask yourself is, what is the size of the audience you’re targeting.  Within that question, what would you consider minimal marketing penetration to even consider pushing ahead with the initiative: 10% of the target segment?  25%?  More?  When does it reach viability? 40%? 50% etc.etc.  

The same four screens named in #1 are used to assess in advance the acceptability levels for each one – minimal, viable, complete and loveable – for each aspect of the product and marketing strategy development.  These aspects could include elements such as:

a. Design system compliance

b. Design implementation

c. Measuring success

d. Feature prioritization

e. Feature completeness

f. Technological/operational performance

g. Clarity

h. Product lifespan

i. Decommissioning process

Here are a couple of examples of passing each one of the four stages through one of the elements above.  Take “Design System Compliance”.  How could you define each of the four stages for system design?

• Minimal.  What are the least requirements we place on design system compliance in terms of marketing?  At minimum, it should be designed to learn through existing components.  Learning can be anything, such as customer targeting, next-most-likely product to buy etc.

• To be viable, though, it needs to go beyond existing system components and add new elements that will be appended only if they achieve a significant impact (say, 5X the current performance).  In other words, add targeting tools, for example, that will yield 5X or more new customer inquiries or applications.

• A complete design will unify existing systems with any new components in compliance with the brand identity.  All enhancements are now seamlessly incorporated into the initial system but with far improved performance and results.

• Loveable is truly idea, say when all bugs are identified and corrected.  It’s an aspirational stage.

Each stage can be defined quantitatively (for example, Design Implementation can include a minimal level of functionality that is required to soft launch, say 30-50%, followed progressively by greater functionality) or qualitatively, as the first example demonstrated.

Feature completeness is another clear example of the thought behind the process.  

• A minimally accepted feature is one where you can generate the learning needed from the feature.  

• It becomes viable when users can actually benefit from the function.

• A complete feature allows users to complete all important part of the journey from entry point to goal.

• And a loveable feature goes beyond the necessary function to provide unexpected functions and feedback which exceed expectations.

One key aspect to the process is a deeper understanding of the product lifespan, something we rarely do in our business. We generally implicitly assume that all products are eternal.  And yet, they are not.  Ask yourself, what is the length of time that is sufficient to validate your product?  Some FinTech companies target 3 months as the make-it-or-break-it period until minimal stage is achieved.  We have never operated at this speed until PPP.  But now we know it is possible to deliver minimally acceptable functionality at 3 months or even less.  Similarly, we should decide in advance how long does it take to determine if the product or system is viable?  A good yardstick is how long will it take to measure sufficient adoption.  As to completeness, so long as the product remains stable and valued in its current form, it is complete.  Loveability is achieve when the product exceeds value-creation and becomes a delightful aspect of the customer’s operation in its current form.

Another important element to the process is the explicit acceptance of incompletion, mistakes, bugs and other sub-optimal performance aspects at the initial launch of the product or system.  The thought process is, let’s launch as soon as the minimal requirements are met, and then continue to improve, hone and sharpen the focus and performance based upon both market feedback and product performance until we get to completion, and, hopefully, loveability.

Another key aspect is visualizing success before we start the process.  Define what success looks like at project evaluation, even before inception, so that the decision whether to scrap the initiative or invest even more in it will become clear as early as possible.  Key actions and investment decisions can be tied to learning and performance goals.  This is done before a minimal level of results and functionality is even defined.  The product/system are only complete when measuring success is clearly defined, there are goals in place and all important events and usage tracking are spelled out and tracked.

Reams of text have been written on agile development.  Far be it from me to summarize them.  The one thing I know is, it requires a fundamental shift in decision-making and speed expectations, as well as tolerance of error, incompletion and mid-course corrections.  These require a cultural shift from the very top, and I consider that a prerequisite to the ultimate success of our transformation into an agile industry.