Software Research Uncovers 3 Key Factors to New Value

No alt text provided for this image

While digging into endogeneity (false causation) factors between successful ventures as compared to failed ones, researchers at the International Institute of Software Management stumbled onto the primary drivers for value – though persistence and determination are highly correlated to success, they are not the cause; but, the application of those traits to three specific types of discovery are predictably responsible for success. Whereas this sounds like a minor distinction, the ramifications are rather significant.

Factor #1, Discovery of a Solution – finding positive new value. 

Persistent, disciplined, attempts at discovery of a solution to a market need is the strongest predictor of value. As it turns out, it’s not how fast the team creates a solution; it’s how fast the team learns from failed attempts at creating that solution. Whereas we know that 9 out of 10 startups fail, on the surface these failures are often attributed to the team simply lacking skills or know-how; but, in truth, failure at that rate is simply the nature of the work of doing discovery. In other words, discovery of new value requires a critical mass of new learning, and new learning requires a critical mass of disciplined failure. Restated from the perspective of cause-to-effect, the systemic tracking of failed solution attempts in a controlled fashion leads to learning which leads to discovery of a new pile of value. However, since failure is nearly universally avoided, discovery of new value is a rare event; perhaps as few as 1 out of 10 startups discover new value at a critical mass.

To better understand the ramifications of discovery of new value, it might be helpful to contrast this practice with the more common create-value-by-replication approach. Simply put, “replicated value” is the result of producing a product from a known recipe and a known business model. For example, baking loaves of bread from a known recipe and selling the fresh loaves from a high-trafficked street corner stall every morning generates a predictable amount of replicated value. However, discovering a new recipe for bread, or a new business model to sell bread has an unknown value until discovered:

  • the new bread recipe could taste great, cost less and be extremely healthy, (this outcome represents discovery of positive, new disruptive value, aka “discovered value”);
  • or the new bread recipe could spoil quickly and make customers sick (this is discovery of negative disruptive value, aka discovered “chaos”). 

Whereas discovered value at a critical mass can lead to massive business growth, chaos at critical mass can- and will- destroy your business. To avoid the risks of chaos and failure, traditional management teams naturally shy away from discovering value at a critical mass and focus on value replication, optimization, and scaling the business – activities which have less risk and require much smaller amounts of discovery. However, by avoiding failure and focusing on known value-replication best practices, the team is effectively guaranteed to never discover new value at a critical mass.

In the case of software projects, most attempts at ‘value creation’ are a confusing blend of replicated value and discovered value. For example, often the business model and platform are reused/replicated (e.g. the cloud, an app store, a desktop PC or mobile device, having the same OS and software stacks); however, the application or features tend to be new. Whereas the replicated portion of the solution can be accurately planned, the new parts of the solution must be discovered, because:

  • new value is not created, it is discovered via a series of attempts at a potential solution

To maximize new value, discovery must continue until the team has successfully embodied a critical mass of new learning into the solution; the time required to achieve the value goal is unknown and variable. With replicated value, you can plan the activity (how long will it take to bake 100 loaves of bread), and you can adjust your labor to deliver by a desired date. But, with discovered value, effectiveness is a function of the rate of learning, the rate of experimentation, and rate of clarification. It helps to think of the overall solution as a delivery vehicle (i.e. a truck or container). The goal of value discovery is to pack the truck full of a critical mass of value before it leaves; whereas the goal of replicated value is to deliver ‘n’ units by date certain. With value discovery, it’s highly undesirable to have the truck leave until all the boxes needed to hit a critical mass of new value have been packed. Having said that, it’s important to understand that discovery of value requires multiple shipments of change to the market in order to discover an optimal solution.

In truth, most change is not valuable – otherwise, more startup attempts would succeed. When discovering new value, a reasonable expectation is that 1-out-of-10 new solution recipes will have a positive value coefficient. This implies that if you’re attempting to find new value, you should be planning at least 10 potential solution attempts. You can of course leverage emerging research and outside sources of learning to improve your odds of discovering value; but, don’t expect the results to get much better than 1 in 5. In software teams, most successful teams have a value coefficient between .10 and .20. Meaning most of their solution attempts on the path to discovering new value are filler (change that is incomplete, lacking, or simply not used) or, to a lesser extent, chaos (change that actually erodes the value of the solution). Though most change isn’t valuable, the learning gleaned from fail attempts is a prerequisite to accumulating discovered change that is valuable in aggregate.

Thus, teams which learn quickly from their failures while persisting to discover a potential solution discover new value at significantly higher rates than teams that are managed into a couple of constrained attempts at creating a solution by a predetermined date.

Factor #2, Discovery of Chaos – eliminating the value eroding effects of chaos.

The second strongest predictor of value is the determined pursuit of chaos discovery and elimination. To the extent that the new product offering changes, or for that matter, to the extent the business model changes, there must be a corresponding amount of chaos discovery. Otherwise, as your solution changes, undiscovered chaos will accumulate until it reaches a critical mass, potentially erasing all the value that you have previously discovered. For example, in the case of a software project, if the platform hardware changes, network-security model changes, operating system changes, or other software components change, to the extent they’ve changed, there must be a corresponding attempt at discovering chaos. If this type of discovery is overlooked or deferred, instability and incompatibility will accumulate until your discovered solution is no longer viable. 

In the instance of software, chaos is usually the result of fragile code executing under unexpected conditions which are either data, timing, context, access or disruption related – things like race conditions, partial or bad data, multi-threaded/non-reentrant code, dropped connections, unexpected security challenges, unhandled exceptions, environmental disruptions, etc. Chaos often results in leaving the device, system or application in a highly undesirable state. Clearly, if your airplane, pacemaker, or just your business is depended on millions of lines of code functioning reliably millions of times a day, chaos is a bad thing.

Like new value, chaos is a side-effect of change. However, unlike new value, chaos is virtually guaranteed to accumulate until explicitly dealt with by a deliberate kind of intervention best described as statistical chaos control and remediation. Statistical chaos control is an emerging quality assurance discipline having four steps:

  1. Add native instrumentation to the code
  2. Run instrumented code in production or under a representative load (typically both)
  3. Collect and monitor normalized health measures that wrap end-to-end functionality looking for sliding averages that exceed two standard deviations
  4. When a KPI measure exceeds two standard deviations, dig-in and figure-out why

In human terms, this is like listening to an airplane’s engines for unusual noise before take-off. If the engines don’t sound right, it’s probably best to find the cause before taking-off. Of course, bad software often doesn’t make an audible sound, and bad software doesn’t have a flight recorder like an airplane, and whatever data that happens to be written to a log (i.e. “got to line 182 and x = 2”) often isn’t well suited to pipelining statistical comparisons. The goal of statistical comparison is to listen for unusual noise. In teams that search for chaos, the listener is typically a neural network of some kind (usually a human analyst or lead developer) who periodically compares statistical outcomes to known good outcomes. When the listener hears or sees something atypical, it throws an exception resulting in a determined search to discover the root cause, ideally prior to the plane taking-off.

As an expert at listening to digital engines who is also a seasoned software engineer, I regularly note a variety of uncontrolled chaos accumulating in the industry’s products and services. To effectively address this issue requires consistent vigilance on the part of software teams and managers who both must agree that they can’t afford to overlook statistical chaos control. 

Not surprisingly, teams and companies that purposefully pursue chaos discovery in proportion to solution change realize customer value at much higher rates than teams that don’t.

Factor #3, Discovery of Traction and Scaling – keeping the original team engaged.

The third predictor of value is keeping the original team engaged during transition from discovery of solution, to discovery of traction and discovery of scale. It’s helpful to think of this critical step to actualizing value as the completion of discovering of a new, reliable business model. This is most efficiently done using the original team, allowing them to approach the discovery of traction and scale similar to any other desired new value – namely, new value must be discovered from a critical mass of new learning which by necessity requires working through emergent, new forms of failure!

Discovery of traction is the search for an effective means of socializing a market segment who needs your solution, customer by customer, segment by segment until you’ve reached market saturation, having penetrated 84% of the addressable market.

Discovery of scale is the search for an effective means of replicating, packaging and deploying the discovered solution. Again, this is most efficiently done with the assistance of the original development team.

As you would expect, if your discovered solution lacks a critical mass of value, or if it possesses a critical mass of chaos, it is statistically highly unlikely to achieve significant traction or scale. Unfortunately, the presence of initial traction doesn’t automatically mean your solution has positive value – this is another type of false causation which should be avoided. However, if your solution continues to lack traction, it does mean that one or more of the following is true:

  1. Your solution lacks value at a critical mass
  2. Your solution has accumulated chaos at a critical mass
  3. And/or, you have yet to discover an effective means of socializing your solution

The good news is, teams that stay engaged through traction and scaling phases of a product or service predictively achieve traction and scale at much higher rates; and therefore, they actualize value at much higher rates.

Assuming that the first-two factors have been addressed with the effective help and guidance of the original team, the remaining traction related causes are likely due to a combination of the following:

  • The market lacks an understanding of its need – with truly new products and value, the customers’ understanding of their need usually requires customer development.
  • Discovery of an effective means of socializing the solution – this must be found, built or bought. It could be as simple as advertising; but, the strongest embodiments usually somehow facilitate a delighted customer’s natural desire to share the solution with their friends, co-workers, and family. These sorts of embodiments are often best facilitated with the assistance of the original team.
  • Discovery of an effective consumption trigger – this requires deep understanding of the customers’ needs and how they manifest which is best discovered by the original team. The ultimate socialization goal is to build a strong association in your target market between their need-deficit manifesting and their awareness that your solution will reliably fulfill that triggered need – Especially in the past, but still in use, marketers often used the creation of “jingle” to help form this type of association. For example: “you deserve a break today, so get up and on your way to… <insert famous, unnamed fast food restaurant>”
  •  Establishment of a brand – this is best achieved by building trust in a name by reliably meeting a type of need, and consistently exhibiting integrity in the fulfillment of that need.

Having a good understanding of a customer’s needs doesn’t automatically translate into knowing how best to market to those needs. Because, the best means of facilitating traction of a new product or service must be discovered by attempting a “traction solution” that furthers understanding and awareness of the four points above; again, some failure should be expected.

Nevertheless, by leveraging the original team’s knowledge and accumulated know-how, you can predictably realize new value at much higher rates. You will, of course, benefit by augmenting the original team’s abilities with sales, marketing, production and delivery expertise as part of the transition from discovered value to replicated value. Fair warning: ignoring this research will most certainly result in slowing-down new value realization significantly by prematurely insulating the original team from these crucial discovery activities.

Putting Together the 3 Key Factors to New Value

Though the details of how best to discover these factors vary by problem, by product, by market and by team, the big-picture objectives of “what to do” remains the same:

  1. Accumulate a critical mass of positive new value by persistent solution discovery
  2. Prevent a critical mass of negative value by determined chaos discovery
  3. Reach a critical mass of customer adoption by persistent traction and scale discovery

As leaders of creative teams, it is important to understand that new value isn’t created by plan, it’s discovered by learning from failed attempts at creating a solution. Therefore, it must necessarily be our jobs to stop avoiding failure and to start celebrating new learning and afford our teams the time and investment they need to do the critical work of value discovery. Because, in the final analysis, new value is not created, it is discovered.

------------------------

No alt text provided for this image

Our mission is to strengthen Software Leaders at every stage of their career. Learn more about mission at iism.org/mission. Please consider becoming a member at iism.org/register.

Do you have a team that’s struggling with chaos accumulation, or perhaps you have a team that would benefit from stronger value discovery practices? iiSM.ORG provides on-campus training which can be requested at iism.org/training-come-to-my-company.

Our pledge is to reinvest funds from training fees into more groundbreaking research and the public publishing of software management training materials and related certification programs which can be found at iism.org/materials and iism.org/career-store respectively.

Nancy Nitsche

Venue Management Systems/ Customer Experience Management/ Hospitality Technology (Hotels, Concierge, Day/Night Club, Pools, Sports Lounges, Experiences and more) - TechDirector of Sales

1 个月

This is a really good article and interesting how such a slight change in application can have such a significant impact.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了