Agile Zone is brought to you in partnership with:

Lukasz Szyrmer is an author, an award-winning public speaker, a mentor, teacher, and community activist. He enjoys the challenge of distilling complex technical and organizational ideas down to their essence, so that others can benefit. He has previously inspired many people to systematic self-improvement. With a background in economics and finance, he currently develops multithreaded, real-time financial software for hedge funds in C++ and C#, and also contributes to product management. Lukasz is a DZone MVB and is not an employee of DZone and has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

Modularity = Faster Time To Market

01.22.2014
| 10415 views |
  • submit to reddit

One of the key reasons scrum and agile have become increasingly popular is that Agile enables you to get to market faster. Faster time to market changes the game. If you understand why this compression of time works, you will be able to compress it even further. Agile shortens the fuzzy front end. Iterative development allows you to be highly effective, changing tactics as your environment changes. You can “parallel process” the creation of features. Most importantly, you can create modular software that helps you assemble a product with the perfect combination of features, a whole product.

Many software projects previously were just left hanging over the void, clutching the overhang, hoping for the best. Many projects initially languish in a state of cloudy vagueness. “Yeah, we should take a look at that.” A few weeks pass. “Yeah, maybe we should take a look at that.” A domain expert leaves the company. “Now we can take a stab at this.”

This indeterminate scope actually causes significant delay. In addition to the actual problem to solve, somebody needs to figure out the business case for doing the project. It’s not immediately obvious it will make money. Is it a problem worth solving?

Historically, this meant specifications, spreadsheets, and sometimes even a song and a dance to get budget sign-off. Biggish companies–particularly guilty. Once all of this was complete, and only then, the geeks wrote the first line of code.

Then it started. The pressure was on. The developers raced to finish each feature, meticulously described in arcane language and symbols. Once the developers finished their magic, a few days before the deadline, the entire weight of the project was dumped on a stressed-out QA team. A few gallons of coffee later, and after a series of boardroom fistfights about what features can be dropped since the original deadline was manic, the team releases a turd.

Of course nobody can say that. The product website sings the praises of how indisputably amazing the product is. The drooling sales team yell “To Market, To Market to Sell a Fat Pig”. The developers go on vacations to the Bahamas to drink away their bad memories of creating the turd. Then nobody buys it. Or worse, they buy it, and they tell their industry buddies the product smells, feels, and acts like a turd.

[Side Note: no pigs or other animals were harmed during the creation of this software. All of the above was purely fictional. Any resemblance to real life projects the author worked on was purely incidental, except for projects pre-dating the Y2K bug.]

ASSEMBLING A WHOLE PRODUCT

One of the groundbreaking concepts in technology marketing: the whole product. In Crossing the Chasm from the go-go nineties dotcom era, Geoffrey Moore pointed out that many technology companies grow rapidly in the years, and then hit a wall once they try to make their product more mainstream. Once the same technology is put into the hands of a mainstream buyer, such as a operations director who approves big ticket IT buys within a large company, a completely different set of criteria emerge. What changes? An 80% solution isn’t good enough. It has to be a 100% solution.

Early technology audiences are fascinated by gadgets, science, and technology. They love an intellectual challenge. For them, there is no such thing as half-finished product. In fact, they prefer to assemble components into a completely new object, one that solves a problem they have. The prototype is what they want the most. This is true even for existing technology. There is great excitement in understanding how a transistor radio or clock works, especially if you construct one from your own transistors and boards. In many cases, providing them a finished product robs them the adventure of creating something new. They don’t want a complete solution. They want to build their own.

The Raspberry Pi is a perfect example. It’s a Linux box the size of a credit card. It’s cheap. It tickles the geek’s imagination. You can use it for anything from watching Youtube videos on your large screen TV, to building custom electronics. It has a USB port. Any programmer can now work with hardware, without actually soldering anything. While it captures the imagination of creative developers, it’s just a really small, inexpensive PC. It comes in a small box. It needs a number of other parts to be useful, such as a monitor and a keyboard for example.

In constrast, mainstream audiences want a complete solution. This is called a “whole product”. A whole product fully solves a specific problem for a particular type of user. Pragmatists don’t care about potential applications. They just want to pay some money, and then be certain they can stop worrying about a particular type of problem. This is most of any technology market.

Moore writes:

The concept is very straightforward: There is a gap between the marketing promise made to the customer – the compelling value proposition – and the ability of the shipped product to fulfill that promise. For that gap to be overcome, the product must be augmented by a variety of services and ancillary products to become the whole product.

The main example he gives is that of an e-book reader, which at the time was practically unheard of. Today we have the Kindle, the iPad, the Sony Reader, all of which have been successful in the market. At the time, Moore guessed there were a number of potential applications, each for a different segment of the market. Each viewed the product through a different lens. A student wants to carrying many textbooks. A student wants light textbooks. A professional wants to have up-to-date documentation distributed electronically.

Excel is a good example of a whole product, both then and now. Not only is the software reasonably stable, there is ample documentation, thousands of forums, hundreds of books. Every office assistant will claim to know something about Excel on their CV. At the same time, you can hire a programmer which can create customized macros to query data from the internet, downloading everything from amazon reviews to World Bank economic data.

The problem is that many tech companies systematically under-deliver, leaving the customer flabbergasted. They aren’t actually seeing the problem from the non-technical perspective of specific customers. The essence of the high tech marketing problem according to Moore: “high tech deliver[s] 80 to 90% of a whole product to any number of possible target customers, but 100% to few, if any.” Some of it may be attributable to rapid changes in the technology itself. Some of it is just an unwillingness to sympathize with less technical users who don’t want the challenge of completing their whole product.

It’s similar to the old anecdote of a young boy who bought his grandmother a hockey stick for Christmas. While she’s happy she got a well-meaning present from him, the grandmother can’t really use the hockey stick for anything that she particularly cares for.

In order to turn a techie product into one accepted by pragmatists, it needs to be adapted and customized to all of their expectations. To make it even more of a challenge, each particular niche will have a slightly different set of expectations.

Published at DZone with permission of Lukasz Szyrmer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)