The bullwhip effect is a phenomenon where small changes in one end of a system can cause large fluctuations in another end of the system. You’ll see it most frequently associated with supply chain and logistics imbalances and fluctuations in demand and supply with amplification of variability in demand.
An adjunctive area of thinking is around the cobweb theorem in economics which relates to market price variability as a result of those same market supply and demand elements. The bullwhip effect can lead to excess inventory, lost revenue, and overinvestment in production whereas the cobweb theorem can lead to radical swings in market prices.
The bullwhip effect and the cobweb theorem are related because they both show how small changes in demand can cause large changes in supply. Ultimately both relate to imperfect information and associative reactions in end-to-end system that are not perfectly aligned or coordinated, leading to overreaction or underreaction by the system participants.
Bullwhip effects and cobweb based pricing in particular often lead to inefficiency, waste, and instability.
Effects on software development
One of the systems that can experience the bullwhip effect is software development. In the process of creating, testing, and deploying software applications that meet the needs and expectations of customers I see many stages and participants. Product managers, sponsors, developers, testers, development managers and of course customers, and users. At each stage the participants have different information and incentives that affect their own decisions and actions.
The bullwhip effect can occur in software development when there is a mismatch between the actual demand for the product or features in the product and the perception of demand in the minds of those within the software organization.
A customer may request a minor enhancement for example but those involved in the development process may interpret this as a major change and vice versa. More or less time and resources may be invested in the development of feature or capability than necessary. Let’s also be clear. Changes may also be triggered by other imperfect information, such as the relationship with the customer’s value in the software house’s revenue contribution chain or the software adoption lifecycle within the customer. Customer X may be a household brand but make a small bottom line contribution or customer Y may be an unknown brand yet have significant economic value to the business and a host of other possible combinations in between.
All of these factors can lead to software product delivery delays, overruns, and potential waste. If the customer requests a major change in the software, but this is underestimated, this can lead to an inadequate results, errors, defects, and customer dissatisfaction and the risk of loss.
Interpretation of requirements is so critical and yet so often overlooked beyond the face value of the ask. Sometimes “the ask” is also founded on anecdotes and opinions instead of evidence, insufficient modelling, the absence of prototyping and minimal market feedback. It is almost as if we fear hearing the critique and are just eager to build a solution.
There is also the proverbial problem of poor communication or handoff of requirements among the various participants. This can lead to distorted information and inaccurate requirements as a whole.
When stakeholders place overly ambitious demands on product or development teams or make decision pivots in an erratic or irregular way instead of making progressive, small incremental changes regularly, you can land up with spikes of activity, abandoning of initiatives in flight and incomplete work. These lead to resourcing and planning confusion, delivery crises and potentially wild cost variations. Everything becomes urgent and predictability on delivery goes out the window in favour of the latest new shiny thing.
Delivery crises or cost and estimate variations introduce uncertainty and anxiousness into the delivery assurance and process and negatively impact the potential usefulness of the roadmap and delivery plans. Promises or suggestions of intent made today settle as dust for tomorrow.
Deals contingent on feature delivery, renewals contingent on feature delivery; omissions of detailed fact, allowing unchallenged assumptions to be made about the presence or capability of features and an over-optimism on actual capabilities relative to real and present functionality encourages and perhaps even induces customers deals but creates feature alignment uncertainty and ruins the best made roadmap plans and planning in general.
Product and engineering managers have seen it time and time again; in start-up software houses it is perhaps the worst of all. Hunger for the commercial deal leads to over promising without due consideration of the impact to roadmap execution plans for existing commitments and other competing customer priorities or issues all in pursuit of business growth.
Demand information, such as feedback or analytics data, that is not shared or not used effectively by the organization as a whole, could have a direct impact on scheduling and resourcing and could result in poor coordination and planning.
Human behaviours, such as greed, exaggeration, or panic can influence offers and commercial decisions especially in times of economic uncertainty or at critical time junctures in the calendar like month, quarter or financial year end to meet quotas or squeeze budgets.
The product backlog
From a backlog perspective, timelines often become elongated, feature backlogs grow and actual product output may crawl, developers may land up producing software features uniquely designed for particular customers or industry segments in response to commercial obligations rather than in alignment with the mission of the business or a given product line’s vision.
There can be loss of revenue too, where features and capabilities are developed in a “misaligned with the market” way. Since developers are often the order takers from product management or executives, they rarely have the real opportunity to dispute the relative priority of things and opportunities may get missed, features may get rushed and the completeness of capability overlooked in favour of a “get it out fast” mindset, all in pursuit of perhaps a box checking exercise or to meet the narrowest of possible needs and expectations quickly.
Feature proliferation without market validation and qualification is effectively overinvestment or misplaced investment. A feature ROI will reveal that some features that seemed great in principle effectively become part of a wasteland of technical debt in production. The features may not be valued and worse, may not be used or adopted at all and removing them may be more expensive than simply having them linger in the product in perpetuity.
Poor quality is often also a result of the bullwhip with developers producing software inconsistently or of a low quality, buggy, unreliable, or incompatible with customer or user expectations. This in turn leads to lowered customer satisfaction, where customers or users are unhappy with the software features they receive or do not receive.
Remediation strategies
The bullwhip effect can be reduced or prevented in software development by adopting some neutralising strategies.
The first of these is an improvement in communication where there is the deliberate use of clear and consistent language, documentation, and feedback without guile or hubris.
This means practical down to earth descriptors that relate to state, opportunity and need. This may be in relation to opportunities, actual customer situations or on the flipside, a changing situation in relation to the state of the technology landscape or resources required to the work. The communication has to go both ways, servicing demand and supply aspects of the business. Developers tell technology stories and account managers tell customer stories. Product managers play back both sides.
Smoothing demand is really about settling on a product execution plan that works for everyone. This is achieved by actually being forward thinking and prescriptive about the product roadmap, features and functions. Providing enough detail to assuage concerns about progress but no so much detail that it becomes a road for the back in terms of execution. General direction of travel and progress markers are what count.
Focusing on intentions for the product based on the core values of the business and how the product lines up against those. The challenge here is for businesses with a small or emerging foothold in the market and a young or small product portfolio that they are trying to evolve. All that said, by choosing a narrow market segment rather than anything and everything with a potential pulse, your software business is focused on where the sales effort investment is likely to yield the best possible opportunities. Customers that are too big may be overbearing, those that are too small may be too expensive to service.
Pricing is often very contentious. A combination between science and the dark arts, it is difficult to always get the price for products perfectly right at the beginning. For this reason, many software products start with a relatively straight forward pricing model that becomes infinitely more complex and sophisticated as the size of the customer opportunity grows and the deals mature. You want to leave just enough money on the table to not feel that you undersold your product.
This may sometimes lead to hockey stick pricing models that seem super affordable or even free at low levels but then grow exponentially according to use or data or something like that – these strategies often leading to debates about value based pricing models. Attempts at price banding, price stepping and the like sometimes help. When these are combined with multiyear discounts or contingencies and other complex calculations, customers and sales people sometimes may get equally confused and the value to cost understanding compromised. This in turn can lead to horse trading or bidding wars, price gouging or ballooning. Poor thinking on pricing can be a destabilizer for investment runways it can also extend them. Be prepared to always rethink your pricing.
Customer churn considerations usually only kick in after the first anniversary of the sale but again, when considered in relation to pricing, feature development, cost to serve and the relative value of the opportunity to the software vendor, these can have an extraordinary and disruptive effect on software development lifecycle management as the customer’s specific backlog requirements get dusted off and get given elevated priority to ensure renewal, all with the limited context of a renewal at risk.
Sharing details on opportunities that have specific needs and expectations should happen regularly. The main participants in this process of communication should be the account teams and the product management team. Nothing should ever be promised to prospects without a clear understanding of the criticality of the requirement to the prospect, the relative position of that thing in a backlog (it may not even exist), the alignment with the product vision and a good understanding of the cost to service the requirement and optimistic timeline. I’d encourage customer teams to regularly involve product management in their customer qualification process also. Product managers crave the indulgence of not just customers but also prospects, as bystanders in the product demos and discovery sessions, they get to hear about the customer context problems and are best positioned to spot opportunities for product improvement or enhancement first hand.
Finally, it is worth considering that all of this relates to managing human behaviours. By educating and motivating all the teams to make rational and informed decisions based on facts rather than emotions one is better positioned to deliver superior software products consistently and affordably. By applying these strategies, software development houses can likely avoid or minimize the bullwhip effect and improve their operational and process efficiency, quality, and customer satisfaction.
Photo Credit: Pexels : Photo by Müşerref İkizoğlu