Utah Open Source Planet

Download purchased MP3s from Amazon more than one time? Not without intervention from tech support.

I began trying Amazon's MP3 download service recently, and was initially pleased with the results. After purchasing a track I could visit the 'Your Media Library' section of the site and download my previous purchases, even if I was at another computer.

Not anymore.

Amazon will let me pay for the same track twice(albeit with a recently added warning), but there is no longer an option on the site to "redownload" tracks already purchased, _unless_ you contact Amazon's technical support. The following video screenshot displays the warning without any option to download content previously purchased.



This is further complicated by a lacking website implementation of the Amazon MP3 Downloader application, which only works if the Amazon MP3 site sends an 'AMZ' file to download cover art and create Artist\Album folder directory trees. If the site sends you an MP3 file instead of an AMZ, you get the pleasure of creating your Artist\Album folder directory trees manually!

Should you choose to cancel the download after purchasing, the site will not let you try to download the track again unless Customer support triggers a magic bit. And should you receive an MP3 file download prompt instead of an AMZ file that works with the Amazon MP3 Downloader, the whole cycle repeats itself.

At the very least Amazon could allow users an option to default to downloading AMZ files instead of a manual MP3 download.

Allowing users to choose to download AMZ files would have prevented me from attempting to download files to the same computer twice. But there was not a choice. After initiaing a purchase, the MP3 download was initiated, and that was it. I tried leaving the Amazon MP3 Downloader running, reinstalling it, and modifying the browser settings to force AMZ files to open in the Amazon MP3 Downloader instead of the default associated AMZ app(which was already the Amazon MP3 Downloader). Again, if an .MP3 download is already started by the Amazon web site, it's too late to try a second time to get the AMZ file to launch.

This also means accessing your purchased tracks on another computer is no longer a feature. It's been recently yanked.

Amazon was pretty quick to respond to my inquiry, but could they do more?
Here's the text of their response:

Hello from Amazon.com.

Amazon MP3 files are only available for download at the time of purchase. We display information about the items you've purchased from the Amazon MP3 Music Downloads store in Your Media Library so you can keep track of what you've bought and discover similar items that may be available. However, the files are not stored there and cannot be downloaded again after purchase without intervention from Amazon MP3 Support on an exceptional basis. This has always been the case with our downloads.

Because you can only download an MP3 file once upon purchase, we encourage you to make back-up copies of your MP3 Music files to ensure you will always have access.
[info about browser/cookie config removed]

Amazon claims this functionality has never been available. Methinks it has been removed in the last month, because I was able to download tracks more than once that I had purchased via the 'Your Media Library' without contacting support.

Amazon could do more to ensure that their customers receive the digital media purchased. Amazon's customer service has been handled well in other areas... why put the burden on the consumer, when the site can allow multiple downloads of previously purchased content?

Is this a digital iteration of forcing consumers to buy media more than once, similar to moves from VHS to DVD to Blu-Ray?

Nope. It's worse. In this case the consumer's second purchase does not include any additional value. The burdens of data integrity and recoverability are placed upon the consumer. Don't be concerned, because Amazon has a service that can be used for backups, too.

Team size can make a big difference in the success of your service or product. What is counterintuitive for most people is that the larger the team size, the lower the likelihood of success for your service or product.  Why? Entropy can set in and large teams are inherently bad vehicles for communication. More insipid, however, is that the larger the team, there is a higher likelihood of accountability and responsibility being diffused across the team.

When accountability and responsibility is massively diffused, then the mantra holds: if everyone is charge, then nobody is in charge.  In this article, I quantitatively show the inverse relationship between team size and productivity & how team size does impact the effectiveness of communication and accountability & the eventual success of the service or product.

I’ve written about efficient teams before here and here. When I was at Amazon, teams were organized into small, delta teams called “2-pizza teams”: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –

• 2 people are smarter than one
• 3, 4, 5, 6, 7, 8 people are smarter than 2
• a team larger than 9 people is just a big dumb gelatinous blob (acronym: BDGB)

Okay, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members. The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams.

A more quantitative explanation is as follows:

One of the root causes of failure in projects is communication — either a lack thereof, miscommunication, or hand-off’s.  Large teams are inherently vehicles for bad communication. This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

For the number of pairs, we can reduce the above formula to the following:

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

A Rejoinder

Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.

A Conclusion

There is wisdom in Bezos’ notion of the 2-Pizza Team. Small teams — provided you have the right people — work incredibly well. Also, there is wisdom in Toyota’s usage of Obeya or “The Big Room” as a way to mitigate defects caused by large teams. A combining of the two will most likely make for a great team and a successful product.

Articles on Ethnography and Design:

1. Feature? What Feature?
   
2. Simplify The Product
3. Ask Aza Raskin
4. Aza Raskin on Poka-Yoke & The Humane Interface
5. Aza Raskin on Quasimodal Design and The ATM
6. Aza on Feature-Bloat and Site Clutter
7. Aza on Google Search Results Page
8. Aza on Cooperation and Team Size
9. Design Thinking in Medicine
10. On Designing a Watering Can for Little Hands
11. Queueing Theory and Visual Management
12. An Interview with the Inventor of “Clocky”
13. Bad Breath but Good Design
14. What is Ethnography

Articles on Leadership:

1. Overmanaged and Underled
2. Colin Powell on Leadership
3. Team or Staff?
4. Tipping-Point Leadership
5. Abraham Lincoln on Leadership
6. How to transform an Organization: Chime-in Before Buy-in

Articles on Queueing Theory:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree
• Attitude and the Psychology of Waiting - The Psychology of Queueing

Articles on Operations, lean and six sigma:

• Managing Constraints Under Peak Volumes
• Order Pipeline of Events
• On Game Theory
• Applied Regression Analysis
• 5S
• Click-to-Ship Processes
• Kanban Sizing and “Pull”
• Lean at Krispy Kreme
• Theory of Constraints and Camping
• Lean for Software Development
• Don’t Waste the Customer’s Time
• Featuritis and the Focus on the Customer

Rich Wolski from University of California, Santa Barbara is speaking about an open source implementation of cloud computing that has an interface compatible with Amazon's EC2 called Eucalyptus.

Rich does research on grid computing. He's been looking for the "open source" cloud. He mentions Numbus (Univ. of Chicago) and Enomalism. But nothing came close to what they wanted: Linux image hosting ala Amazon.

By choosing to make their interface compatible with EC2, they take advantage of all the client side tools that work with EC2 to manage machines in Eucalyptus. They want one-button install of their system on top of a cluster of machines.

The goals:

• Foster research in cloud computing
• Create a vehicle for experimentation prior to buying commercial services
• Provide a debugging and development platform for EC2
• Provide a development platform for the open source community
• Not designed as a replacement technology for EC2 or other cloud services

Challenges:

• Extensibility - simple architecture and open internal APIs
• Client side interface - Based on the EC2 WSDL and 2008 compliant except for static IP address assignment and security groups. There's no public information on system administration of the cloud, so Eucalyptus provided it's own interface for that.
• Networking - VPN per cloud. Public IPs are scarce, so all cloud images have access to a private network interface, but not public interfaces.
• Security - authentication and authorization. All Eucalyptus components use WS-SEcurity for authentication. Intercomponent messages are not encrypted by default. SSH key generation and installation 'ala EC2 is implemented.
• Packaging, installation, maintenance - uses Rocks. They want to change this.

Lessons learned:

• Open source for cloud computing constrains design more than they thought it would. Local configuration choices provide real challenge.
• No one in the real world still build clusters by hand.
• There are few cloud computing configuration tools available.

Tags: velocity08 automated+infrastructure amazon web+service cloud+computing

I’d venture to say that most products and services are bloated with features that customers most likely don’t care for;  I’ve been part of product development teams where the focus is on features, with an implicit goal to stuffing as many features as possible — in consumer packaged goods and in software.   This is the wrong approach to developing memorable and sticky products.

The above statement might be best described by Kathy Sierra’s Featuritis Curve:

In my own personal venture in product and package design (a side project), I employ ethnography — the science of watching people do stuff; of learning about unarticulated customer needs, which is otherwise known as ethnography; Toyota calls it Genchi Genbutsu.

A.G. Lafley, the CEO of Procter and Gamble, understands this well:

JANUARY 28, 2005, Business Week

I wanted to get after what we call unarticulated consumer needs. What she wants that she can’t tell us about. And there are lots of techniques we have developed or are developing to do that. And two, I wanted to focus more on the consumer experiences as much as on the product and technology.

People remember experiences. They don’t remember attributes or benefits or features.  We talk a lot about how you create a delightful experience.  Now, when you’re dealing with underarm deodorants and cleaning dirty floors, you have to work real hard to try and deliver a less unpleasant experience.

The key phrase here is this:

People remember experiences. They don’t remember attributes or benefits or features.

What a simple, yet profound statement that still many, many companies fail to understand.

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree
• Attitude and the Psychology of Waiting - The Psychology of Queueing

For a few articles on Operations, lean and six sigma, please visit the links below:

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and “Pull”

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

ShareThis

With Amazon's Web services, you've been able to store stuff in S3 or SimpleDB. You've also been able to fire up as many machine instances as you liked with storage that went away when you shut the machine down. Anything you wanted saved better be in a database somewhere else, or you had to painstakingly copy it out to S3 yourself. Last night Amazon announced persistent storage on EC2. Now you can create disks in S3 and attach them to EC2 instances. You want a terabyte of storage for your machine, just create it in S3 and mount it.

Another feature rolled out last night is snapshots. Need backup or the ability to rollback? Snapshot the instance and it's on S3, ready to use. You can create new volumes from any particular snapshot.

These two features make Amazon's grid computing platform a very nice place for startups to experiment, develop, and build out. All with little or no capital cost.

Tags: amazon web+services

A friend of mine recently contacted me, seeking my advice on how to get a job at Amazon.com; my friend is a top-notch software engineer, manager, and an all-around good person and leader.  The job he is interested in is for a position as a software development manager in reverse-logistics at Amazon.com.  My friend qualifies on most items, except for the last bullet below, requiring experience in Lean Manufacturing and Six Sigma — for a software engineering job!:

Qualifications

• Substantive experience building innovative, complex software, ideally but not necessarily web based systems
• Strong technical credentials, with at least 3 years leading or managing software development teams, ideally with some hands-on architectural or distributed systems experience
• Business analysis acumen, with experience measuring the success of a complex business and proposing new business opportunities
• A record of great hiring of technical team members and leaders
• Operational support and passion, with experience in establishing, measuring, and meeting service level agreements, improving the availability, performance, and quality of systems
• A track record of communicating well with executives and non-technical leaders
• Experience in account management and vendor management preferred
• Bachelors Degree in Computer Science or the equivalent strongly preferred
• MBA preferred
• Experience in Six Sigma and Lean is a HUGE plus

The last point gave me an enormous smile, from ear-to-ear.  Because of Amazon’s intense secrecy, most people do not know how engrained Lean Manufacturing and Six Sigma are in the Amazon.com culture.  For me, when Lean and Six Sigma show-up on job requisitions for software development jobs — that, to me, is a huge success indicator that Lean and Six Sigma is becoming more and more a thread throughout the company.

Jeff Bezos is sharing more and more on this topic.  In a recent Harvard Business Review article, he said this about Lean Manufacturing and Six Sigma:

As the business grew and moved into new areas, you must have felt challenged to keep up on a personal level. What have you had to learn along the way?

Something we haven’t talked about, but that is super important in our culture, is the focus on defect reduction and execution.  It’s one of the reasons that we have been successful for customers.  That is something I had to learn about.

Well, by “learn” I mean I literally learned a bunch of techniques, like Six Sigma and lean manufacturing and other incredibly useful approaches. I’m very detail oriented by nature, so I have the right instincts to be an acceptable operator, but I didn’t have the tools to create repeatable processes and to know where those processes made sense.

Before I started Amazon, I was with a quantitative hedge fund. That work is very disciplined and very analytical, but it’s not a question of designing a repeatable process. It’s not like a car-manufacturing plant, where the work has to be done in a defect-free way, in the same way over and over and over—or anyway, that piece of it is not as important.

But here, that execution focus is a big factor, and you can see it in our financial metrics over the past ten years. It’s very obvious when, for instance, we look at the number of customer contacts per unit sold. Our customers don’t contact us unless something’s wrong, so we want that number to move down—and it has gone down every year for 12 years. That’s big-time process management. We try to implement those kinds of processes in various places. They’re most naturally applied in our fulfillment centers and in customer service and so on, but we’ve actually found that they can be useful in a bunch of different things.

When you are inexperienced with disciplined process management, you initially think that it’s equivalent to bureaucracy. But effective process is not bureaucracy. Bureaucracy is senseless processing—and we’ve had some of that, too.

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree
• Attitude and the Psychology of Waiting - The Psychology of Queueing

For a few articles on Operations, lean and six sigma, please visit the links below:

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and “Pull”

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

ShareThis

Jay Ridgeway from Nextumi (click to enlarge)

This afternoon, I was torn between the session on botnets and one on Amazon's SimpleDB by Mike Culver and Jay Ridgeway. I chose the latter.

The goal is a durable, flexible datastore at a cheap price: $0.14 per machine house, $0.10/Gb into the cloud and $0.18/Gb out.

The API call list is short. Domains are used to partition data. You can think of them as tables, that helps. To add something to a domain you use this syntax:

PUT (item, 123), (description, Sweater), (color, Red), (color, Blue)

The first name-value tuple is the name of the row and needs to be unique. The remaining tuples are attributes and names can be repeated to represent a attribute with multiple values. There are no datatypes. Everything is a string.

A query looks like:

Domain = MyStore
['description' = 'Sweater']

Note that this isn't SQL. :-)

There's a Javascript application called SimpleDB Scratchpad that can be used to play with SimpleDB. All you need is your AWS key.

Jay Ridgeway from Nextumi took the mic to talk about their experience using SimpleDB to implement ShareThis. They've made heavy use of SimpleDB. He concluded with the following list of downsides and upsides. On the downside:

• Limited features
• minimal toolset and documentation
• no experience in house
• high switching cost

On the upside:

• zero software cost
• minimal staff costs
• low barrier to development
• responsive and reliable
• simple, pragmatic solution for a complex problem.

Nextumi does maintain a copy of the raw data in case Amazon ceased to exist for some reason, but using it would obviously require some redesign of their site. I wonder if anyone has created the SimpleDB API on top of BerkeleyDB or MySQL? That would be handy.

SimpleDB doesn't handle binary data well. The best thing is to put binary data in S3 and put a reference to it in SimpleDB.

Tags: etech etech08 aws amazon databases

Team size can make a big difference in the success of your service or product.  What is counterintuitive for most people is that the larger the team size, the lower the likelihood of success for your service or product.  Why?  Entropy can set in and large teams are inherently bad vehicles for communication.  In what follows, I show quantitatively how team size does have an impact on the effectiveness of communication and the eventual success of the service or product.

I’ve written about efficient teams before here and here.  When I was at Amazon, teams were organized into small, delta teams called "2-pizza teams": no team should be larger than 2 pizzas can feed.  It’s a great approach to team size.  In my short career, I’ve learned how true that rule is.  Here’s another thing I’ve learned –

• 2 people are smarter than one
• 3, 4, 5, 6, 7, 8 people are smarter than 2
• a team larger than 9 people is just a big dumb gelatinous blob (acronym: BDGB)

Okay, that’s not true at a wholesale level, but it sure feels like it.  A small team with highly smart and capable team members can do much more than 10 mediocre team members.  The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams.

A more quantitative explanation is as follows:

One of the root causes of failure in projects is communication — either a lack thereof, miscommunication, or hand-off’s.  Large teams are inherently vehicles for bad communication.  This is basic combinatorics — for a given project, suppose there are persons A and B.  In this scenario there is only 1 communication link.  Add person C, now we have 3 communication links, A-B, B-C, C-A.  Add person D, then we have 6; Add person E, then we have 10 communication links.  Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly.  To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

For the number of pairs, we can reduce the above formula to the following:

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

A Rejoinder

Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed.  Caution, is what I am arguing here.  The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone.  If the product requires a large team, then expect the above challenge and manage it.

A Conclusion

There is wisdom in Bezos’ notion of the 2-Pizza Team.  Small teams — provided you have the right people — work incredibly well.  Also, there is wisdom in Toyota’s usage of Obeya or “The Big Room” as a way to mitigate defects caused by large teams.  A combining of the two will most likely make for a great team and a successful product.

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree
• Attitude and the Psychology of Waiting - The Psychology of Queueing

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

Did you know Amazon has a Social Network?  In fact, it’s pretty robust!  In Amazon, if you click “(your name)’s Amazon”, then “Your Profile”, you have the option to set up a profile, including a biography, information about yourself, and get this - a list of all your friends currently on Amazon.com. It can show your recent purchases, your favorite items, your wish list, and more. It even gives you a blog in which you can send messages to those that are friends with you. You can also import your own blog’s rss into the blog feed. Amazon has even MySpace beat, with an activity feed of recent activity by your friends.

The real power comes for authors. As an author, I can have people add me as a friend, and I can keep an open dialog with my readers. I can introduce deals, notify when new editions of the book are released, and more. You can see my favorite books, movies, and music, my wishlist, and my biography. You can also see the other books I have written. Amazon also lets you verify through a publisher or agent that a book was written by you, so your books on Amazon can link back to your profile.

Amazon has quite a tool here that I wouldn’t put past them building on in the future. If you think the MySpace OpenSocial announcement was big, imagine if Amazon were to embrace an API such as OpenSocial. In the USA alone, Amazon has over 60 million members in its network. Each one of those members is tied to a bank account of some sort and has probably bought something at some point from the site. Add to that the existing APIs Amazon provides, allowing users to query the Amazon database, associate affiliate IDs and sell items based on commission, Amazon could have the first proven revenue model for a Social Network.

Amazon and Google aren’t the best of friends. Would Amazon embrace Google’s OpenSocial, or create their own as they have through Amazon AWS? Visit my Profile and add me as a friend on Amazon!:

http://www.amazon.com/gp/pdp/profile/A1NYWKPQAI1F5R

Share this article with a friend...

On average, most business processes are inefficient  and create an unhealthy amount of waste: once you learn to see the process waste all around — with Lean Thinking as your worldview — you will notice overprocessing, transportation, overproduction, waiting, inventory, motion, and defects.  Aside from our processes producing waste, our processes also create burden on our people and also burden on the earth. 

A company that I once did some work for was very concerned about the burden it was placing on its people and on the earth.  In what follows, I will show that a firm can still be enterprising, care about people, and care about the earth. 

As a review, let us first discuss Value, Waste, and the perspective of the customer.

What is a Process?

A process is an systematic activity comprising of smaller activities that culminate in an outcome — service or product. A process can take up time, space, and resources. All processes can be categorized into the following categories: Value-added, Non-value added but necessary, and Non-value added.

From the Customer’s Perspective:

1. Value-added: This step in the process adds form, function, and value to the end product and for the customer.
2. Non-Value-Added: This step does not add form, function, or assist in the finished goods manufacturing of the product.
3. Non-Value-Added-But-Necessary: This step does not add value, but is a necessary step in the final value-added product.

(2) & (3) naturally create waste, of which there are 7 types:

1. Over-Production: Producing more than is needed, faster than needed or before needed.
2. Wait-time: Idle time that occurs when co-dependent events are not synchronized.
3. Transportation: Any material movement that does not directly support immediate production.
4. Processing: Redundant effort (production or communication) which adds no value to a product or service.
5. Inventory: Any supply in excess of process or demand requirements.
6. Motion: Any movement of people which does not contribute added value to the product or service.
7. Defect: Repair or rework of a product or service to fulfill customer requirements.

It’s important to understand “Value” in terms of the customer.  From the customer’s perspective, “Value” could be defined in the form of a question:

Which process steps (and associated costs) do our customers not have to bear?

It’s a revealing question — most companies are glad that they do not have to reveal how their product or service is created, for fear of their inefficient processes and wasteful operations revealed to the customer.  This stance is sometimes aptly called "not revealing how the hot dog is made", amicably referring to the unknown contents of the hot dog.

Burden on People; Burden on Earth

It is easy to see how the 7 Wastes above add substantial cost to the firm, reducing it’s margins, and negatively impacting the customer.  But, what is less obvious is the burden that inefficient processes have on the earth. 

I was on the Supply Chain and Logistics side of this company.  This company aimed to reduce usage of packaging and wrapping material through simplifying specifications for packaging and wrapping and by promoting the use of returnable containers or bins.  As a result of the efforts of a lot of caring people, this company reduced its volume of packaging by 15% than the previous year.  Below is a picture of the results:

What is remarkable is that by lessening the burden on people by reducing the weight, bulk, volume, and material used for packaging, the earth also benefits because there is less CO2 used and less material is required to the same work.  What is not highlighted is that safety and ergonomics was also a huge benefit — people now deal with less weight, bulk, and volume, which makes for a safer work environment. 

This reduction of material used is a big win for People and for the Earth.  What is also important, though less important than People or the Earth, is that costs were reduced by a substantial amount, which increases the gross margins of the firm, making shareholders very happy.

A False Dichotomy

Contrary to popular thought, there is an opportunity to be a good steward of the earth, take care of people, and also be an enterprising capitalist.  The example above is a case study that supports that fact.

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

I just posted piece at Between the Lines on Amazon's latest announcement: SimpleDB, a database service in the cloud. I gave it the title "Economics that are impossible to stop" because that what I think Amazon's doing: changing the whole economic model of how people build large scale distributed applications.

Tags: amazon web+services databases cs462

I just want to say that I love shopping at Amazon. The checkout makes it the best. After I find what I want and go to checkout, it is quick and painless. I love. I also use my Amazon card that pays me $25 for every 1500 points. What a deal. My wife likes it the best. I told her she gets to spend them. If you want a card you can find them here at www.plasticrewards.com. Another great site for find credit cards.

Peak Season at Amazon was so fun and memorable. 

There are two peak season — the inbound peak and the outbound peak.  Inbound is when inventory is brought into the Fulfillment Centers (FC), which is around August to September.  Thanksgiving and beyond is the outbound peak season.  It’s a busy time of year and was super fun. 

Below is a picture of a Fulfillment Center that only deals with what is knows as "Full-Case, Non-Conveyable", which means that the items are too large to place on a conveyor belt.  

Bruno Vincent/Getty Images

Yeah, that’s a ton of stuff.  From a Lean Manufacturing perspective, the ecommerce model is challenging because we’re dealing with highly variable orders on both mix and quantity and the delicate balance between service level, inventory availability, and holding costs are incredibly challenging.  Heijunka, or Production Leveling in this environment, is quite challenging.  Multi-Echelon Systems are very interesting, to be sure.  Fun times for sure and a dream come true for an Operations, Logistics, Supply Chain, Six Sigma, and Lean geek like me.  In fact, when I taught at Brigham Young University’s Marriott School, several of the case studies my class worked on were from my experience at Amazon. 

Calling on All Former Amazonians

This is an invitation to all former Amazon employees to join the Amazon Alumni Group on Linkedin.  I own the group and we currently have 142 members that were former employees at Amazon.  Some of the former Amazonians are now at Google, eBay, Facebook (9 at Facebook on my last count), Peerflix, Jobster, Microsoft, Last.fm, Yahoo!, TripAdvisor, and at many other high-flying, not-so-high-flying, and other interesting ventures.   To join, please follow the instructions below.

If you were an employee at Amazon, please join the group (must be logged-in on Linkedin).  You can also search to see who the current members are and what they are doing these days.   To be a member, you must show on your Linkedin profile when and what you did at Amazon.com. 

If you are friends with a former Amazon employee, please help spread the word and invite them to join the group.

Disclosure: I was formerly at Amazon in various roles and am thankfully still a minor shareholder.  From an insider’s view, Amazon has warts and zits like every other company, but is generally a very well-run company.  Bezos’ adoption of Lean Manufacturing, Six Sigma, and an absolute focus on the Customer and the Amazon Core Values are really what is keeping the company focused.  "Customer Obsession, not Competitor Focused" was the Amazon mantra and something that has stayed with me. 

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

I just posted piece at Between the Lines on Amazon's latest announcement: SimpleDB, a database service in the cloud. I gave it the title "Economics that are impossible to stop" because that what I think Amazon's doing: changing the whole economic model of how people build large scale distributed applications.

Tags: amazon web+services databases cs462

Aza Raskin is the founder of Humanized, the son of Macintosh inventor, Jef Raskin, and an all-around good guy.  A few months ago, Aza Raskin agreed to answer several readers’ questions.   In today’s post, Aza Raskin tackles a reader’s question about Product Management, cooperations with other groups, throwing stuff over the fence, why large teams generally suck, and political in-fighting and politics.

I work as a product manager for a technology company in the valley.  In large companies like mine, the department of Product Management, Software Engineering, and Customer Experience work together, but in a clunky way, to build a product.  What is the best way, in your opinion, to infuse the Humane Design Principles in a hot political environment?

Maybe you should start an "Ask Aza" column, like a Dr. Phil segment, or something.

Successfully bringing a product to market is a holistic endeavor.  User requirements drives customer experience; customer experience drives marketing; marketing drives user requirements.  Nobody should feel that a set of requirements has been "thrown over the fence".  When this happens, the recipient-of-the-throw is beholden to an abstract deliverable and is no longer connected to the end-user.  That’s a real problem.  Combating this requires a tight-feedback loop which is most easily created with a small team: engineering gets to see the market research come in, and the usability people can guide engineering throughout the actual creation process.

In an ideal world, everyone on the team would have a foot in engineering, design, and marketing.  Unfortunately, this isn’t always possible.  What is possible is that we can create small, tight teams that collectively have intimate knowledge of all three disciplines.

The small-team idea is by no means new.  In the book In Search of Excellence, Tom Peters explains over-and-over again that it’s the small groups; skunk works, home-brew projects, and strike teams that drive innovation at companies both large and small.  The most successful teams are those of 10 people or less — preferably between 4 and 8 — that include people from the required disciplines.

By keeping teams small, products don’t get commitee-ized.  The team is directly responsible for success.  Success is dependent on making a product that meets the needs of the user and to the user, the interface is the product.

P.S.,  I like the idea of an "Ask Aza" column: Anything that’s alliterative must be good!

Aza’s point above about team size is important, and one that I’ve discussed before.  Quantitatively, we can show why, in general, large teams aren’t the best way to go.  Here is what I wrote back in Ocotober 15, 2006:

Stinky Large Teams: A Proof

I’ve written about the importance of team size before, here, here, and here. Previously, this is what I said:

I’ve written about efficient teams before here and here. At Amazon, there is a concept of a 2-pizza team: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –

• 2 people are smarter than one
• 3, 4, 5, 6, 7, 8 people are smarter than 2
• a team larger than 9 people is just one big dumb blob

Ok, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members.  The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams — especially software teams.

A more quantitative explanation is as follows:

One of the root causes of failure in projects is communication — either a lack thereof, or miscommunication.  Large teams are inherently vehicles for bad communication.  This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

For the number of pairs, we can reduce the above formula to the following:

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

A Rejoinder

Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.

A Conclusion

There is wisdom in Bezos’ notion of the 2-Pizza Team.  Small teams work incredibly well.  Also, there is wisdom in Toyota’s usage of “The Big Room” as a way to mitigate defects caused by large teams.  A combining of the two will most likely make for a great team and a successful product.

+++++

Other articles in the "Ask Aza Raskin" Series:

1. Ask Aza Raskin
2. Aza Raskin on Poka-Yoke & The Humane Interface
3. Aza Raskin on Quasimodal Design and The ATM
4. Aza on Feature-Bloat and Site Clutter
5. Aza on Google Search Results Page
6. Aza on Cooperation and Team Size

+++++

Articles on Queueing Theory

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

+++++

For articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

Bijan shared this great, real-world experience of how getting the basics perfect is, in fact, a loyalty driver: his experience? — with Amazon.com Customer Service.

In his words,

Two weeks ago I bought an item on Amazon. It was a toaster oven.

In my haste I shipped it to my brother instead of my home address.

Even worse, it was my brother’s old address so the product was shipped to the wrong house and I don’t know the owner. Even worse, that new owner signed and accepted the shipment.

I called Amazon and told them the whole story. The customer service rep put me on hold for 2 minutes. Then he came back on and told me that they would like to send me the item to my home address w/out an additional charge. I said thanks very much. Two minutes later I received a confirmation email.

Amazing customer service.

Amazon rules.

Then, In the comments section, a reader asked:

They improved, they were not like this before. I remember when you could not call them and email response took days.

And, Bijan, responded — no — he defended, Amazon.com Customer Service:

Actually calling them by phone was very easy. They use click-to-call so I just punched in my phone number, the service calls me immediately and then I’m connected to customer service.

Bijan’s experience with Amazon.com Customer Service was an act of the simple basics, in my opinion.  But, it is a clear example of how getting the basics right can lead to loyalty, as evidenced in Bijan’s praise for Amazon and also in his later defense of Amazon.com Customer Service in the comment section of his blog.

The Amazon.com Core Values

The Amazon Core Values are realized in the way they treat the customer — also, they are hard-core in every Amazonian.  Specifically, the Amazon Core Values are:

• Customer Obsession: We start with the customer and work backwards.
• Innovation: If you don’t listen to your customers you will fail. But if you only listen to your customers you will also fail.
• Bias for Action: We live in a time of unheralded revolution and insurmountable opportunity – provided we make every minute count.
• Ownership: Ownership matters when you’re building a great company. Owners think long-term, plead passionately for their projects and ideas, and are empowered to respectfully challenge decisions.
• High Hiring Bar: When making a hiring decision we ask ourselves: “Will I admire this person? Will I learn from this person? Is this person a superstar?”
• Frugality: We spend money on things that really matter and believe that frugality breeds resourcefulness, self-sufficiency, and invention!

Indeed, Customer Obsession — we see it and hear about it, over and over again.  It’s true: getting the basics perfect can lead to customer loyalty. 

disclosure: I was previously employed by Amazon.com and am still a shareholder in the company.  To this day, I remain a fanboy of Amazon but also know about its warts and issues.

Related Articles on Amazon.com:

1. Jeff Bezos on Lean Manufacturing, Six Sigma, and Amazon.com
2. A Draggable Timeline: Acquisitions of Google, Microsoft, Yahoo, and Amazon.com
3. The Mind of Bezos
4. Join the Amazon Alumni on Linkedin Group
5. Start with the Customer, and then work backwards
6. Customer Obsession
7. Focus on the Customer
8. Giving away my old Amazon.com schwag
9. Click-to-Ship: Delivery Process Times
10. Traceability, Visibility: Is Your Company a Black Hole to the Customer?
    

Share This