Below Water Level

Data shows that upwards of 75% of products fail.

[Source]

Pendo.io’s research shows that 80% of features do not get used.

[Source]

None of this should come as a surprise though. Software is delivered to a large extent based on someone’s feature request, or someone’s attraction to a shiny object, customer requirements, feedback, resume building, competitor comparisons, for making a sale, executive or board or investor pressure or may be just lack of understanding of the customer or the user. Those are some of the reasons behind the massive indictment of our industry and the $29Bn dollars of waste.

More Waste Than Meets the Eye

Failed products or unused features might on the surface appear like one off costs. But the reality is that features, once they are in the product, amplify the ROI erosion through training costs for those features, maintenance of website pages and marketing material, customer support queries and KBs, engg. tech debt, and even management attention to make sure everything else coming up in the product works with those 80%.

Because such features or products have not originated in some strategy or logic or choice-making exercise, they cause further waste due to misplaced priorities, leading to the wrong things being worked upon. Even though the features themselves may be defined well, they may still lead to lost money, time and opportunity because they were not the right thing to work upon.

To correct gaps in understanding or rationale behind such features or to provide “leadership” perspective on them, meetings and presentations need to be organized much after the work has already begun. These meetings cost an increasingly large part of employee time. The increasing time spent in meetings is largely a reaction to absence of a systematic problem shaping and selection method.

Once the feedback from the field does come in, the product or feature requires rework all the way through to the first step. This is expensive especially when the stakeholder work is done late in the lifecycle of the product or feature. Many times, teams may not even action such feedback at the risk of delaying the feature or product.

Lack of excitement, unclear rationale, absence of logic behind features and ambiguous or non-existent acknowledgement of the impact of the product or feature on other stakeholder leads to friction. Friction among stakeholders causes damage to relationships, blame games, lack of support and resources, or just plain old ambivalence about the launch. The friction increases reluctance to work together in the future. The distance and separation cause even more breakdown in the machinery for future launches.

Waste is A Problem of Method

As I covered in a previous post, there are a lot of ways in which waste manifests itself in software. This is not a problem of intelligence or culture or resources. This is a problem of method. i.e. the method we use to figure out what gets built and what not. The method underpins how we figure out the feature definition and selection logic. The method underpins the choices that we make everyday. I will be covering that in more detail in another post.