In our work with Cyara customers, the Domain Consulting team has found many examples of organizations approaching software development the same way: with the business side dictating their requirements to the technology side. But I believe that to encourage buy-in from the technology team as well as a better outcome, the business should be sharing their objectives or outcomes instead. In this post, I will outline my reasons and give some examples as well.
One-Sided Equations
We’ve seen this scenario play out again and again. The business side of the organization shares their list of requirements for a product or feature with the technology side, and tells them to go ahead and meet those requirements. It’s a very common practice.
But when the business throws a list of requirements at the technology team, that can very often be uninteresting for the technology team. The technology team can bring a lot more to the table than just implementing requirements.
In the past, this has stemmed from a lack of mutual trust from both the business and the technology teams. The business side might feel the tech team doesn’t understand their perspective, and vice versa. But I think this is less and less true. More and more technologists are attuned to the business side of things, and more and more people on the business side understand and are conversant with technology.
Focusing on Outcomes
Instead of this approach, both sides of the business should be focusing on outcomes or objectives. When they do, it encourages continuous exploration and the delivery of more valuable solutions.
For the technology team, it’s a lot more rewarding to come up with a solution than to implement a solution somebody else has come up with. It also opens up opportunities for collaboration and different perspectives — if someone on the tech team feels there’s a better way to achieve the desired outcome, they can voice that. This encourages buy-in from more team members and ultimately leads to a better solution.
I’ll illustrate this idea with a use case around “cost to serve.” Very often, the way we see our customers operate is that they’ll identify that a service is costing too much, possibly because the self-service rate isn’t satisfactory, and agents are getting involved too often. A requirements focus would suggest fixing the IVR self-service application. But the best way of fixing the issue might be to revisit what the objective was, because they might realize that the self-service is not, in fact, the biggest issue. The problem may be how customers are authenticated, or that self-service in the IVR isn’t the best way of serving customers. It may be better to redirect customers to the website using visual IVR, or to a mobile app.
Organizations need to determine the best way of achieving the outcome in the shortest amount of time with the smallest amount of money. From there, they need to validate the assumptions that they’re making. Often it’s a combination of solutions, so it’s best to investigate and pursue different options in parallel if they can.
How to Share Outcomes
Our advice is to start by doing divergent thinking. Start with the objective and then come up with as many ideas as you can to meet that objective. At the end of the session, take a vote to choose the top 3 or 5 ideas that have merit, then explore those options. They can be explored in priority order or in parallel if possible. Go through the concept of doing an MVP or a minimum marketable feature. If the option will achieve the outcomes you want, continue to invest in it and deliver new features and improve it. If it’s not working or having the impact you want, pivot and make changes that will make it work, or abandon it. The idea is to work on options, or make small bets, to see what works. If it works, expand on it, and if it doesn’t work, cut your losses.
How would focusing on outcomes benefit your organization?
To learn more about how Domain Consulting can help you, contact us, or get in touch with your Account Executive.
