Who Moved my Product Value?

Posted by Mukund Srinivasan on Jul 05, 2010

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Value ,

Agile ,

Adopting Agile

Tags

Adoption

Agile and Life Cycle

At the outset, it seems like agile is all about short-term focus and a product life cycle is typically the polar opposite – it runs the total gamut in the spectrum that is the life of the product, starting from incubation to end-of-life. So, how does one attribute the relationship between the two? This is where product value comes in.Taking a philosophical question-and-answer approach to determining this intricate relationship, we can ask a very basic question: who are we building a product for? The answer is simple: customers. How do customers attribute the benefits derived from the use of a product that they pay for? Again, the answer is simple – it is notional value. This is the basic definition of product value. Over the years, this definition has evolved from its simple origins to a rapidly transforming lexicon that is built around product value. This is because the value or the definition of it has changed quite a bit in the past decade.

Where’s my value?

In my quest to determine the true definition of product value, I read quite a bit of complex literature around process and the whole life cycle evolution in the software world. But, I got nowhere with the complex approach. I did get the answer, though, when I least expected it.

It started off as a fairly innocuous catch-up topic; a seemingly innocent dinner-table conversation when I was recently exchanging industry trends with the General Manager of a well known, respected and $2Bil.+ revenue driven product and engineering services conglomerate (all that, just to corroborate the seriousness of the opinions being represented!). The topic of discussion was the diminishing distinction between products and services in today’s technology space. Soon, I started equating that perception to Agile and scrum; before we knew it, there it was, threadbare – it wasn’t just the products and services per se that were getting blurred into one. Rather, the sensitivities of the changing (and quickly at that) marketplace are what put the most strain on technology businesses today.

The pressures of having to deliver to a competitive industry have grown exponentially within the last decade. This, exacerbated by the tough economic conditions the world over, has forced companies – big and small – to look for enhanced agility and nimbleness to “software delivery”.

You get what you pay for!

Whilst this statement might be true for most products and commodities (with higher premium usually equated to better product standards), it makes for some interesting analogies in the technology space. Apparently, research shows that 45% of the features in a product never (ever) get used by the majority of its users. So, in the software industry of the 90’s, the equivalent catchy phrase should have been:

YOU PAY FOR WHAT YOU NEVER USE!

Now, try selling that line to your sales guy, let alone your customer! Take a look at this for vindication:

Surely you’re joking, Mr. Feynman

To the layman it might not be seemingly apparent as to where this is all headed, or what this has got to do with Agile or Scrum. To the trained eye, it couldn’t be more obvious. If you take the added dimension of when Agile started becoming more pronounced as an accepted practice, it will dawn that it was not a mere coincidence for it to gain prominence in the last decade when this became much more of a ground force, or groundswell, from its origins as a “nice in theory” practice. Now, this has been the exact decade when the technology boom happened as well, with waterfall being the primary practice of delivering software and solutions. It doesn’t take a trivia genius to put two and two together to demonstrate that the value for customers diminished with waterfall because:

1. Features were being developed with a target persona in mind that changed quicker than the product time-to-market window thereby rendering most of the features useless by the time it really got to the market.
2. Rewards weren’t commensurate – there were promising technologies that fell by the wayside because they weren’t nimble enough to change courses midway through development.
3. A product’s value wasn’t in the number of patents contained within, or the ingenuity of it all – make no mistake, that did indeed play a part – but, the biggest bottom line contribution came from how much value add it provided. This meant changing requirements all the time, and didn’t allow for 6 months of just perfecting a solution to a single problem. It became critical to be adept at maneuvering the product development through its rapidly changing life cycle.

Technology adoption curve

The picture is fairly self-deciphering: the technology adoption is specified by the user persona in the various stages of the business life cycle: innovators setting the stage for early adopters, who demonstrate the viability for the early and late majority to cash in, followed by the late entrants who are adept at “making up for” the gross margins with volumes. The Product Life Cycle is demonstrated as well on the X-axis: with “finding niche” and “EOL decision” making up the two ends of the gamut, in the life of the product, over its living course.

To the mathematical readers, the concept of “increased frequency or reduced wingspan” of this bell curve will immediately convey the message of what’s happening in the market place today. To the less mathematically inclined, all that says is that the span of each phase in the product-lifecycle is shrinking, and rapidly. What was perfectly acceptable to deliver 18-months apart, is now “expected” to happen matter-of-fact in 9 months or less. This doesn’t mean that the workforce is doubled, nor is the complexity lesser now by any stretch of imagination. So, the only piece left to balance the equation is “adaptability” and to a slightly lesser extent, efficiency.

Conclusion

With adaptability driving the decision-making from the helm and change being the only literal constant – now more than ever – it points to only one way of delivering working software and value to customers. And that’s simply by being Agile, with tools like scrum to aid the process. Anyone disagree?

1. Back to top

   I don't believe the durations shrink that much

   by Andy Dent

   It's a nice argument and well-illustrated but I don't believe your core assertion about how much the lifecycle is shrinking. What significant software products that are in regular use by business fit your data?
   
   I also don't believe that businesses have significantly adapted their cycle from the 12-month accounting-based cycle they had when I started nearly 30 years ago. Purchasing for major items is still being budgeted on an annual basis, in any of the places I've worked at in the last few years.

   Reply

2. Back to top

   research shows that 45% of the features in a product never (ever) get used

   by Dickey Singh

   Thanks for the writeup. Well represented.
   
   Could you please point me to the source of research you have mentioned?
   
   "research shows that 45% of the features in a product never (ever) get used by the majority of its users"
   
   Thank you!
   Dickey SIngh

   Reply

3. Back to top

   Re: research shows that 45% of the features in a product never (ever) get u

   by Dickey Singh

   Never mind - I found the source in the Pie chart.

   Reply

• Older >