AGILE Product Development Adapted for Business Transformation Projects
In agile product management, the primary focus is on iterating quickly in order to provide incremental value through product enhancements. This is based on the assumption that it is difficult to know if an idea will actually provide increased value, so it is best to try something, measure the results, and adjust accordingly in quick succession. This method was developed as an alternative to the "waterfall" approach in which groups often failed trying to solve for everything at once since it is difficult to understand the full scope of any problem from the onset (i.e. you don't know what you don't know). Within the software world, this often manifests itself in practices aimed at delivering incremental functionality as quickly as possible, where teams are evaluated on velocity above all else. In many domains, that works incredibly well. However, there is a nuance which I feel is too often overlooked in that business automation software, particularly that which supports core business processes, is tightly coupled with the business process itself.
Take for instance the decision of where to place an ad within the Facebook UI. Should they appear in a static position within the top left rail or should they be placed within the list of posts that users scroll through? The answer to that question isn’t particularly clear without experimentation and it’s relatively easy to segment the massive population of Facebook users into two groups, one getting each variation, and then measure the conversion rate of identical ads. Because of the massive user base and technical tools that support easily segmenting traffic, it’s easy to test different ideas with a small enough group to de-risk material loss of revenue while still providing enough data to be statistically significant.
For example, when an organization is migrating to a new ERP (Enterprise Resource Planning) platform, the general problems are better understood than something like introducing a net new product line - every company on the planet needs to invoice customers, pay vendors, and deliver financial statements - and the gains in operational efficiency and enhanced reporting capabilities are dependent upon everyone involved in accounting processes adhering to standard operating procedures. Standardization of processes make them less mentally taxing to follow and provides clean, consistent data points to be leveraged for making better business decisions based on improved visibility into financial performance (which is ultimately the entire point of an ERP).
This means that the cost of experimentation is high, as people don’t adapt well to constant changes in how they perform their jobs and a lack of alignment across groups makes it difficult to quickly shift resources around within the organization or onboard new team members. This lends to increased importance on change management efforts when deploying new tools or features and their related business process changes. The introduction of new tools that no one uses fails to deliver any benefit to the organization, while non-standard use of those tools may actually cause a loss in operational efficiency and create incomplete or inaccurate data.
Contrast this with the competitive advantages driven by additional features that differentiate a product from its competitors and it is clear that business process optimization is ultimately a way to reduce costs. Such expense reduction strategies inherently have a lower limit of zero, whereas there is theoretically no limit to increasing revenue or strength in the marketplace through the delivery of additional customer-facing features.
Based on this nuanced understanding, it seems fair to slightly alter the general heuristic to include consideration for both the maturity of a product line’s business model as well as the size of the organization. In practice, large enterprises will likely achieve the optimal mix of operational efficiency and flexibility in product monetization models by bifurcating processes and systems into groups. Mature products with a strong position in their given markets are likely better suited for standardization, while those yet to be fully proven may benefit more from the flexibility to quickly adapt the business model.
Additionally, there are some general exceptions where a process such as accepting payments or providing technical support significantly impacts the customer experience. The value of outstanding execution in these areas goes beyond cost reduction, bleeding into competitive advantage, often making them better candidates for highly agile product development processes.
1. Tightly couple the introduction of new tools or features with re-design of related business processes while maintaining focus on the desired business outcomes, not the features created.
2. Capitalize on the fact that your users are members of your own company who you can directly ask about their needs.
3. Gather feedback and iterate prior to release by reviewing solution design before building anything, hold demos for end users to provide commentary, execute multiple User Acceptance Testing (UAT) sessions, and/or release to a smaller pilot group (i.e. beta release) first.
4. Deliver fewer, larger changes along with extensive change management to ensure the full value of the intended process changes and accompanying features is realized.
The optimization of many core business processes is a relatively well understood problem, making stakeholder interviews, analysis of historic data, and the examination of case studies a valuable, low-cost alternative to experimentation for driving requirements.
When do agile product management techniques make sense?
Solving Novel Problems
As I’ve pondered this question, I keep coming back to the idea that success in the implementation of these techniques is highly dependent on the idea that there is little certainty in the predicted outcome. Furthermore, it seems important that success can be easily measured and the cost of experimentation is low. This means that this approach fits best when trying to solve new, unique, or poorly understood problems.Take for instance the decision of where to place an ad within the Facebook UI. Should they appear in a static position within the top left rail or should they be placed within the list of posts that users scroll through? The answer to that question isn’t particularly clear without experimentation and it’s relatively easy to segment the massive population of Facebook users into two groups, one getting each variation, and then measure the conversion rate of identical ads. Because of the massive user base and technical tools that support easily segmenting traffic, it’s easy to test different ideas with a small enough group to de-risk material loss of revenue while still providing enough data to be statistically significant.
Driving Competitive Advantage
Another point of consideration is understanding the relative value of success. As an organization, improving in certain areas is likely to drive competitive advantage and subsequently revenue. In an ever-evolving competitive landscape, the ability to quickly deliver new sources of value to the marketplace is critical in gaining and maintaining a leadership position relative to the competition. The importance of this is heightened when competing in winner-take-all markets, which are increasingly common in B2C software businesses that rely on network effects to deliver value. Just think, social media platforms are worthless in and of themselves; they only provide value when a critical mass of users leverage them, making the fight for market share of utmost importance.Is the automation of standard business processes a good fit?
High Cost of Experimentation
To assume agile product development practices are a good fit for all types of software development is overly simplistic. It is critical to analyze a particular situation to determine if it fits a given model. You have to align the goals of a software development project with the approach most directly in line with delivering the proposed value. I would argue that a slightly different model is required when the goal is to deliver operational efficiency to business processes by leveraging software tools. More often than not, the large gains in value a business hopes to achieve by implementing new technologies are tightly coupled with improved business processes and adherence to them.For example, when an organization is migrating to a new ERP (Enterprise Resource Planning) platform, the general problems are better understood than something like introducing a net new product line - every company on the planet needs to invoice customers, pay vendors, and deliver financial statements - and the gains in operational efficiency and enhanced reporting capabilities are dependent upon everyone involved in accounting processes adhering to standard operating procedures. Standardization of processes make them less mentally taxing to follow and provides clean, consistent data points to be leveraged for making better business decisions based on improved visibility into financial performance (which is ultimately the entire point of an ERP).
This means that the cost of experimentation is high, as people don’t adapt well to constant changes in how they perform their jobs and a lack of alignment across groups makes it difficult to quickly shift resources around within the organization or onboard new team members. This lends to increased importance on change management efforts when deploying new tools or features and their related business process changes. The introduction of new tools that no one uses fails to deliver any benefit to the organization, while non-standard use of those tools may actually cause a loss in operational efficiency and create incomplete or inaccurate data.
Limited Upside
Furthermore, the automation of business processes typically does not provide great competitive advantage. While the inefficiency of some processes may serve as a hindrance to scaling the company, the non-unique nature of most processes simply means that being really, really good at executing them isn’t a reason for customers to choose one company over a competitor.Contrast this with the competitive advantages driven by additional features that differentiate a product from its competitors and it is clear that business process optimization is ultimately a way to reduce costs. Such expense reduction strategies inherently have a lower limit of zero, whereas there is theoretically no limit to increasing revenue or strength in the marketplace through the delivery of additional customer-facing features.
There’s Always a But...
While I believe there are many instances in which the costs of iterating on key business processes outweigh the benefits, I don’t mean to imply the opposite extreme is ideal either or that the general rule is without exception. There are more than a few scenarios in which the value proposition is clearly strong enough to support a drive for quick iterations. When a business is working to introduce a new product line, compete against new entrants in a crowded market, or create a market which did not previously exist, the ability to tweak the business model quickly can be instrumental to success. In some ways this is just a variant of a novel problem; it isn’t clear which model will yield optimal results so the best approach is to try something, measure the results, and adapt as fast as you can.Based on this nuanced understanding, it seems fair to slightly alter the general heuristic to include consideration for both the maturity of a product line’s business model as well as the size of the organization. In practice, large enterprises will likely achieve the optimal mix of operational efficiency and flexibility in product monetization models by bifurcating processes and systems into groups. Mature products with a strong position in their given markets are likely better suited for standardization, while those yet to be fully proven may benefit more from the flexibility to quickly adapt the business model.
Additionally, there are some general exceptions where a process such as accepting payments or providing technical support significantly impacts the customer experience. The value of outstanding execution in these areas goes beyond cost reduction, bleeding into competitive advantage, often making them better candidates for highly agile product development processes.
A Path Forward
Hopefully by now it is clear that using software to automate most standard business processes is a bit different than building the first ridesharing service or AI-based virtual assistant. We’ve taken a look at the characteristics which make Agile product development techniques a good fit: massive upside to success, low cost to experiment, and a limited understanding of the problem. Then we reviewed the reality of Business Transformation projects to discover they often do not share in these characteristics. So what do we do with that information? How can we take the core principles of the Agile methodology and tweak them for maximum effect within the context of Business Transformation projects?1. Tightly couple the introduction of new tools or features with re-design of related business processes while maintaining focus on the desired business outcomes, not the features created.
2. Capitalize on the fact that your users are members of your own company who you can directly ask about their needs.
3. Gather feedback and iterate prior to release by reviewing solution design before building anything, hold demos for end users to provide commentary, execute multiple User Acceptance Testing (UAT) sessions, and/or release to a smaller pilot group (i.e. beta release) first.
4. Deliver fewer, larger changes along with extensive change management to ensure the full value of the intended process changes and accompanying features is realized.
Themes
Great models applied to the incorrect situation may yield results in direct opposition to their intended value.The optimization of many core business processes is a relatively well understood problem, making stakeholder interviews, analysis of historic data, and the examination of case studies a valuable, low-cost alternative to experimentation for driving requirements.
