Managing the tension between technology and business priorities can be a challenge for many organizations. Often, business ambitions are prioritized over improving the technical estate simply because articulating the business case for the technical work is hard. This will ultimately lead to an increased time to market for your products and make it harder for you to respond to customer needs and market changes effectively.
While it's tempting to get caught up in the thrill of building new functionality with emerging technology, a product team's purpose is to solve problems for our business and our customers. Everything that we build should have a clear value articulation: that’s why making a strong business case is critical if you are to tackle technical debt head on.
Paths to production and technical debt
A good example that demonstrates this is when a product has an inefficient path to production. The steps required to improve that path to production may require very technical changes — automated pipelines, repeatable processes and rollback mechanisms — but one way for them to be given priority is to demonstrate and communicate how such changes can improve the speed at which value is delivered to customers; this should, ultimately, improve commercial outcomes for the business.
A similar line of thought can be applied to managing technical debt. Again, the work required to address such debt may be particularly technical; it might, therefore, be difficult for business stakeholders to understand precisely why such work matters and requires investment. Its impact, of course, could be substantial, whether it improves operational effectiveness or the quality of organizational outputs, but product teams need to communicate and demonstrate that — otherwise, doing their jobs will be incredibly challenging.
Asking the right questions
Indeed, failing to communicate these issues can even create tension inside organizations. While it might be frustrating, it’s important that product teams assume responsibility for reducing any tension by clearly and effectively articulating the business benefit. But how do you begin doing that?
The best place to start, in our experience, is by asking a number of important questions:
How will this technical work lead to better business outcomes?
How will this work help us provide better products to customers?
How will this work generate or protect revenue for the company?
How will this work mitigate business risk?
What business metrics will be moved by this work?
What is the potential improvement in these metrics?
"Frame technical work in
light of its value”
Articulating the value of the technical work can bridge any potential disconnect between business and technology and allow the product team to prioritize more technical work that will positively impact the product.
Understanding the underlying problem
Many years ago, Thoughtworks worked with a client who, over a decade, had accumulated a significant amount of technical debt. They were operating on top of a legacy system that directly impacted their ability to sell to their clients and improve user experience. This was having a direct impact on revenue; for instance, 10% of customers could not complete transactions because the payment page wasn’t loading correctly. Modernizing the page, therefore, could correct this and have a direct and significant business impact.
By analyzing internal processes using logs, we could see the payment page would only appear to 90% of customers trying to complete transactions across 15 countries, irrespective of type of payment or if it was onsite or offsite. Moreover, customer feedback suggested that not only was this issue potentially impacting more than 10% of users, some even got stuck in a loop; their only solution was visiting a physical shop in order to complete the purchase process.
For every purchase completed on the site, the team was able to calculate how much revenue would pass through the online sales process and therefore the payments page. We estimated it was about $500,000 (US) per hour in peak traffic across different geographies — our payment page was getting in the way of a successful transaction. Despite other projects and initiatives, our analysis and technical assessment meant we were able to make a clear case to prioritize the work when the opportunity arose.
Making a strong business case
The work to improve reliability of the payment page was done because the product team created a compelling case that addressed both the business and technical aspects of the problem at hand. Key to this was effective instrumentation and monitoring which made it possible to capture the product's behavior and strengthen the business case. Data, such as page load frequency and completed transactions, were effective because they made it possible to draw a clear connection between technical changes and business goals. This made it easier for the team to estimate how much revenue was being left on the table.
What also made it easier was that the organization had started to move from a ‘project’ to a ‘product’ mindset, which focused not on simply delivering digital assets, but instead of developing and maintaining them to maximize user value. This meant there was a cultural shift in which client feedback and satisfaction reports were being taken more seriously, which, in turn, meant there was greater awareness that something needed to be done.
With the organization considering how it might consolidate payments into one single gateway, the business case for making a change to the payment became even stronger. It would effectively allow us to expedite the process of integrating the new gateway in a matter of days; previously it had taken months to add new payment mechanisms. The advantage for the business was clear: addressing the technical debt would not only improve customer experience and improve the transaction rate, it would also change the way the organization could approach its overarching payments strategy.
Despite the clear advantages, the scale of the change meant the process wasn’t straightforward. For this reason, a risk analysis was done to ensure the changes could be properly managed; rolling something out across different territories with different processes could be unpredictable without the right level of planning and oversight. This led to a decision to start the project with the simplest forms of payment and then move to more complex and traffic-heavy markets Technical decisions were informed by business needs and the potential commercial risks.
As each release was done across 15 countries, we began to see improvements in customer experience. The page loaded to 99% of users — they could now be redirected to complete their transaction. This obviously had a financial impact — we saw a 3% increase in the overall conversion rates in global sales.
From articulation to action
Product teams are problem solvers who want to see technology employed to improve customer experience, drive stability and unlock value for the organization.
Providing them with adequate monitoring and instrumentalisation to uncover technical issues impacting the business, allowing them to articulate the value of the work, and empowering them to act is essential in reducing the tension between business and technical priorities.
By clearly articulating the value that technology brings to the product and its delivery, being able to measure the impact of evolving the technological estate, and connecting this to tangible business outcomes, the separation between technical and business priorities dissipates with the conclusion that one can not exist without the other.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
