Every software development organization in the world is claiming that putting the customer first is one of their main priorities and that they will go the extra mile to demonstrate this customer-centricity. But when it comes to translating this customer focus into measurable objectives, the proposed measure of performance is typically quite limited. Most businesses will use KPIs such as: adherence to the project management plan, number of defects per line of code, and tests coverage. Companies will be satisfied with a job well done if the stakeholders within the customer organization (project manager, product owner, architect, etc.) are providing five-star reviews in customer surveys sent after the delivery of the project.
Whilst all the above are absolutely needed, they all focus only on the outputs of the software development process. Meanwhile, experience tells us that there are quite often situations in which despite meeting or exceeding targets for the objectives mentioned above, the application that was created never gets deployed into production or is discarded after a few months in operation. The number one reason for this is a lack of focus on the actual objectives that customers are trying to achieve by implementing a given application. And those objectives are not simply having the application go live and a support setup keeping it running. The objectives will relate to financial performance and are achieved by how end-users embrace the application, their continuous usage of it and the extent to which they make use of all the functionalities built into the app.
Only when focusing on those end-user adoption and consumption objectives can we truly say that we have an outcome-oriented software development and support methodology.
Creating this means embedding the typical end-user journey into the software development lifecycle. The generic end-user journey is made up of the following stages: Awareness, Interest, Desire, Action, Onboarding, Retention, Expansion (AIDAORE).
- The end-user become Aware of the application;
- A high enough level of Interest is created so that the end-user adds this application to the set of alternatives under consideration;
- The Desire to use the application is created;
- A call to Action is presented so that end-users start using the app;
- The end-user is successfully and effortlessly on-boarded;
- Retention is achieved by providing the user with enough value to continuously use the app;
- We Expand the ways a user consumes the application, to include an increasingly wide range of functionalities within the app and providing increasing value.
The first four stages of the journey should be addressed during the work done prior to the go live of the application, whilst the last three should be handled during the support and maintenance phase.
An end-user will start and continue using an application if motivated to do so, meaning the application in discussion addresses a set of needs, and the experience during the usage is flawless. The Motivation is what gets the user through the Awareness, Interest and partially the Desire phases from the journey described before. The Experience is responsible for the rest of the journey.
But nailing both the value proposition, meaning the motivational part, along with the usability part for the application, is virtually impossible at the first attempt. At the same time, addressing the usability aspects before the value proposition, or market-fit, is identified will unnecessarily add extra costs and duration to the implementation.
What this means is that the software development lifecycle must have three main, incremental – and repeatable if needed – phases that will address in this order: the motivation, the usability and the sum of the two in the full-blown application. Within each of the phases a methodology of choice can be used, most likely an agile one, but after each of the phases a gate should exist, and the acceptance to move through the gate should come from the end-users. After each phase the outputs of the phases, respectively should be: the prototype, the Minimum Lovable Product (MLP) and the launch candidate, which must go through usability testing.
Besides addressing the motivation and the usability, in an outcome-based approach to software development, the architectural and functional best practices needed for ensuring the maintainability and quick evolution of the application must be considered. Most important is embedding the software with a sufficient number of end-user experience measurement points. The more, the better. The insights drawn from these will make a world of a difference in the operational phase of the application.
Besides the experience measurements points, other key best practices include:
- Making the application cloud ready as there is a significant probability a given application will have to be migrated to cloud at some time during its lifecycle
- Breaking the application into small components with independent lifecycles
- Preparing the application for a platform-like business model which will imply a full-blown API lifecycle management
- Ensuring the security and privacy
- Making the application a data source – as well as a data consumer – and preparing its integration in the data landscape of the beneficiary organization.
And after we have a validated launch candidate, we need to really focus on Hypercare. I cannot stress enough how important the Hypercare period is. It is the period with potentially the largest impact on the success of the application. The reason for this is because in this period, the initial base of end-users is acquired, and it’s this base that will fuel, via network externalities, the further acquisition of the target user base. Network externalities are the effects a product or service has on a user while others are using the same or compatible products or services. Positive network externalities exist if the benefits (or, more technically, the marginal utility) increase with the number of other users. By understanding this, it is obvious the way we used to look at Hypercare, as the period for achieving application stabilization, is no longer anywhere near sufficient. So the objectives for Hypercare should be:
- Stabilization – ensuring the application works perfectly and fixing Issues
- On-boarding – removing the bumps in end-users’ onboarding and usage; monitoring and acting upon the insights given by end-users
- Adoption – making sure that the customer organization is prepared and willing to embrace the new application
- (potentially) Customer acquisition – via providing services like Digital Media Strategy, Planning and Buying / Performance Marketing & Lead Generation / Conversion Rate Optimization Services / Full PPC (Pay-per-Click) Services
The last two phases of the customer journey must be addressed during the maintenance and support period of the application lifecycle. Usually, in this period, the application support provider is focusing on keeping the application operational and improving the efficiency of the associated operations. Whilst this operational excellence target remains valid – and our digital transformation age has provided some very powerful tools for this – it contributes only marginally to the achievement of the real outcomes that are expected. The expected outcomes are: customer retention and user-base growth. And these are achieved mainly by focusing maintenance on the intelligence drawn from the experience measurements points. From there, the support provider needs to understand how the application is being used, which functionalities are being used and which are not (and why), as well as which functionalities are being used but cause the experience and productivity to suffer. The personas and the usage scenarios must be continuously updated and the application must be evolved accordingly.
It is clear that for a software development organization to truly be able to deliver outcome driven project, the set of responsibilities and implicitly the skills required to be included in the team need to evolve. Such organizations need to include product management and digital marketing specialists in those projects, working in day by day, close interlink with the existing software development team. If and how successfully they will be able to do that could be the difference between success and failure in the following period.
