Delivering the right products and feature sets that your customers need is the ultimate challenge when it comes to giving them the best digital experience, but the key is rolling out what your customers actually need and not what the software development team thinks they need.
My healthcare provider rolled out a great new portal, yet it took 10 minutes to find the “call my doctor” feature simply to make an appointment. While making a phone call might be the last scenario in the workflow for telephony or help center customers, it’s a top priority in healthcare. From an engineering standpoint, the backend design may be better, more efficient and organized, but to the customer, you may have missed the mark. Many times, a priority for software development teams may not be a priority for the end user.
Is This Feature Even Necessary for the Customer?
Further, as dev teams sprint faster and faster, sometimes they find themselves in auto-pilot in order to make those frequent and looming deadlines. However, if we stop for a moment to understand the customer, every one of those product or feature deployments may not actually be necessary. Most likely, not all deployments make sense from a product, cost or efficiency standpoint. How do software development teams determine when a deployment is not actually necessary? How do they determine if they are delivering on what the customer really needs, wants, or will be delighted with?
Here are three factors to turn to when determining to deploy or not to deploy:
1. Define Customer Value
When deploying a product or feature, delivering value to your customer should be paramount. First, how do you define what they value? Before you can determine if you are delivering value, you need to understand what is meaningful to your customers.
This past winter, a co-worker of mine was driving her Tesla in the Boston area shortly after the clean automotive giant rolled out a software update. Half way through her drive, all the windows fogged up. She could not figure out where the defrost button had gone. The user interface screens had all been updated and the button that had been convenient and easy to find had disappeared. She had to pull over to the side of the road, swipe through multiple screens, and pull out her phone and do a Google search. Several minutes later, she was able to figure out how to de-fog the windows.
I’m guessing this re-design was implemented by a software designer on the West Coast, perhaps looking at customer data from the West, where the defrost function isn’t used all that much. So, when re-prioritizing high usage buttons, the defrost button was not flagged as a top priority.
BUT in reality, defrosting is a capability that has huge customer value due to its safety characteristic. When you are fogged up, regardless of where you live or how often this happens, it is imperative that you can defog. By reevaluating and interpreting the usage data with customer value in mind, you make the correct deployment decisions.
You can’t deliver on your customers’ needs if you don’t consider and review what they are.
Related Article: What's Your Ideal Voice of the Customer Approach?
2. Use Customer Data and Methodologies to Prioritize
Using all-encompassing customer data to learn about product usage, limitations and universality of what you are building allows you to prioritize which products and features to deliver. Customer data is most useful to determine what features to deliver next. The best products aren’t built in a vacuum. As you start to understand through the data what the customer needs and what’s valuable to them, adopt methodologies that allow you to scale your work to build the right product.
Whether you have a penchant for API-first or you are a Cucumber Open Behavior Driven Development (BDD) enthusiast, using process or approach to designing products, APIs or microservice is imperative. When organizations abide by a methodology, it allows the team to meet their customers where they are as well as delight them with innovations and fun.
Teams need a way to prioritize their work and design both specific capabilities for a specific customer or solve a problem with an API that has universal applications. Regardless of what you end up building, using and sharing the methodology for how you got to your product with your organization is the key to success. This way, you spend the most amount of time building the most useful products for the maximum number of people.
3. Test, Deploy, Observe, Learn — and Sprint Fast
Just good practice, testing, deploying and learning through gathering customer insights — and doing it again and again — allows you to deliver on the agile software development lifecycle (SDLC) from a formulated approach. Whether you are doing functional testing, API testing or usability testing, feature flagging and sprinting fast allows you to learn if you’ve got the product right.
By feature flagging, you’ll observe, learn and understand the customer’s journey and what’s important to them. The faster you can test and deploy, the faster you can determine if you’ve got the right product.
Sprint fast, learn fast.
Related Article: Agility Is No Longer Optional in Business
Conclusion: Deployment Success Through Developer Visibility
So, the secret to releasing products that customers will buy, use and love? Product deployment success will come through steps 1 through 3 — defining what value means to your customers, gaining customer insights and testing and deploying — as fast as you can.
In order to be enterprise ready and work through these steps, teams need to first be universal and open, allowing developers to choose their methodologies and tools for building the right products. By delivering the right product or feature set with this approach, developers are empowered to observe the product in the wild and learn what’s working and what’s not while better understanding through valuable customer data what is occurring throughout the software development lifecycle.
This authentic approach delivers visibility both operationally and developmentally to teams through observability, customer data, and testing, which ultimately allows developers and scrum teams to make the ultimate decision — to deploy or not to deploy.