For the past several months, I’ve been calling for organizations across the industry to adopt the "red line philosophy" in cloud application development in order to better balance user expectations, quality, and features.
Many developers seem to think that innovation means “new features.” But too often those features don’t quite work as the developer intended or how the end user wants them to work, or they need refinement in order to work better.
The red line philosophy borrows from the Agile movement’s manifesto and its twelve principles, which encourage continuous development and refinement of high-quality applications to improve customer satisfaction. It seeks to tear down the “build it because we can” mentality.
Mathematically, the red line is the total number of issues within applications that are reported divided by the total number of customers consuming the application each month. It helps CIOs better evaluate both how the application is performing and how their development teams are balancing innovation with new features. It helps us deliver applications that do what they are supposed to do efficiently. The red line provides a boundary of what is acceptable.
The red line helps CIOs avoid the "create because we can" mentality, in three ways:
1. Stop unnecessary development
The red line puts a stop to unnecessary development. Often, developers are not aware that there is an issue with a particular feature of an application. The application as a whole may have good adoption from users. However, a particular feature may receive multiple complaints, suggestions for improvement, or other reported issues that are not given back to developers and their teams.
When a red line is first implemented, it provides a communication channel between users and developers. Any issues that users are experiencing is fed back to the development team in a systematic way.
This is crucial to streamline and focus the development process. By knowing what users are requesting, complaining about, or struggling with, managers can steer development resources toward creating applications and features that meet user needs.
For example, on our products and services, we frequently find that users need better documentation or embedded help, and new feature development is not needed to resolve issues. The development work was done adequately enough, but there was a lack of accessible documentation. Or sometimes, a feature needs to have better examples in the documentation. Our users still contact us about these issues, which drives the red line up, but it’s not the code that needs to change. Without the red line, our development teams would not be aware of the documentation issues.
2. Make current applications better
When a red line philosophy is followed, each issue for every application is reported back to a development team. By being made aware of issues and watching trends for reported issues, developers can determine where to focus to improve features within an application.
Too often resources are put toward fixing minor issues that are important to developers or that were outlined in the initial product specification. Rather than focusing on developing features that will not be utilized, the red line ensures that teams will focus only on ways to keep users happy and the business competitive.
If the red line goes up during the quarter, the product team should focus on fixing issues that have been reported by users. This helps to focus the development efforts on making existing applications more efficient and functional – and meeting business objectives.
This is particularly important with new applications where their adoption is crucial to the long-term success of the business. A red line philosophy means resources can be properly allocated where they are needed to improve applications.
If the red line goes down during the quarter, a team can spend their time innovating new services or features. If the red line is flat, the team is balancing quality with innovation. They may choose to focus on innovation but need to maintain their red line trajectory.
3. Spur the right type of innovation
Careless software developers can cause a continually upward-sloping red line. There are developers who thrive on putting out fires and fixing issues – but that leads to a poor user experience. A strategic and solid developer will have a well-balanced red line for their applications as they ensure that customer-driven issues are fixed quickly.
In addition, good developers will balance the red line by finding ways to address other user feedback that may or may not be germane to their application. Because the red line shows trends and provides feedback from users, it allows the developer to be much more strategic and innovative in how to address user needs.
Because developers are looking to balance their red line, they have the freedom they need to innovate the right things when it is appropriate to do so, keeping focused on making the business more competitive. This innovation may come in the way of a new feature, a new application or a new way to use an API within the application – whatever is needed to better support business objectives.
When CIOs implement the red line within their organization, they will find that development teams will begin to phase out the “let’s create it because we can” mentality.
Instead, the red line will focus resources, improve applications, and foster innovation, helping leaders to create a “because it is the right thing to do” mindset.
