Incremental Delivery and Evolving Use Cases

Amazon.com started by selling books. Their initial use case was “Sell books online.” The vision was always “Sell everything” – hence the name. But they started with a simple use case and evolved it.

Evolving Use Cases

Roger Cauvin had two very interesting posts (here and here) about versioned use cases – where he describes the idea of delivering a particular use case incrementally. Roger proposes incrementing use cases along two dimensions, features and constraints. Good articles – check em out.

Amazon provides perhaps the most well known software example of evolving a use case by features. A former CEO of mine told a story allegedly told to him by Jeff Bezos. This CEO was known to use fiction to make a point, so I have no idea if the story is true. Here it is paraphrased:

Jeff walked in on the end of a planning meeting with the founding team of Amazon. They put together a big proposal that was as thick as a phone book, detailing how they would sell everything online – books, CDs, DVDs, housewares, groceries – everything. Jeff picked up the plan, weighed it in his hands, and then threw it across the room and into the trash can and said “how about we just sell books?”

The idea is solid, even if the story isn’t. Jeff wanted to start with books. Essentially, a feature-constrained version of the vision for the company. Over time, Amazon added products, allowing for an evolving version of the use case.

Another famous example might be the Model-T Ford – “Any color, as long as its black.”

Evolution By Constraint

Use cases getting better over time is the easiest way to think about this. Improved usability, improved performance, and increased scalability are all good examples. PlentyOfFish.com started with an ASP 1.0 server, allowing them to support 12,000 concurrent connections – then later upgraded to ASP .NET to support their current 500 million hits per month traffic levels – on a single webserver and single DB server! Now Markus is gearing up for a billion page views per month.

Evolution By ‘More Is Better’

The exact same semantics as the gradually tightening constraints on a non-functional requirement apply here. This is no different than evolving constraints, when the underlying parameter or attribute is represented as a non-functional requirement.

4 thoughts on “Incremental Delivery and Evolving Use Cases”

“He first settled on the concept of catalog shopping without a catalog. He then narrowed his sights further to focus on books and music. He finally chose to just sell books at first, thinking he could get more leverage with the big book publishers than with the big record labels, even though many are parts of the same conglomerates.” at http://www.miscmedia.com/amazon.html

So, maybe it’s true, maybe the premise is true, and maybe its false – guess we’ll never know, unless one of the Amazon employees that reads Tyner Blain (I know there are at least a couple of you) knows the answer…

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!