Month: December 2009
When will retailers learn that having a great website is pointless if you can’t actually fulfill a customer transaction when they want to buy a product?
I was going to quit blogging for the holidays, but then the following happened to me this evening and I had to write about it. A similar problem happened last year on Boxing Day with this retailer. You’d think they’d fix the problem by now!
Future Shop – a large Canadian retailer (http://www.futureshop.ca) now owned by Best Buy – started their Boxing Day sale a bit early this year with a number of online specials.
My wife and I were looking for a new washer/dryer and saw this special:
After a quick bit of online research, we decided to make the purchase. How much better does it get than that for an online retailer?
When I went to checkout and pay for the purchase on the webstore, I got the following screen:
click image to enlarge
This virtual “waiting line” took about 45 minutes to go through. I had to sit and watch that progress bar slowly inch forward. Eventually it reached 100% and then I was greeted with the following wonderful message:
FSDataAccess error ‘800a000d’
/Checkout/CheckoutControlLib.asp, line 79
Yup, after 45 minutes, a coding error. I tried going through the line again (same error) and a 3rd time (same error). At least 1.5 hours wasted on this purchase.
Was it just me experiencing this? Twitter gave me my answer. - Click on tweet images to enlarage
I tried a fourth time — another 20 minute wait to get to the checkout, but this time it was successful — or at least appeared to be. But wait, what’s this message in stage 2 of the checkout? It says, under Stock Status that my item is OUT OF STOCK???
click image to enlarge
But that’s not right, because the product page says there are clearly 2041 of these units in stock!!
click image to enlarge
So, now what gives? I did get a final web page that said an order confirmation email would be coming to my email address. That has not arrived yet. We’ll have to see if Future Shop can actually fulfill a transaction on an advertised special via their website as we appraoch 2010.
Future Shop web site Product Management and Development Teams, a big FAIL to you this Christmas Eve.
Future Shop Customer Service, what are you going to give me for the roughly 2 hours of my time I spent trying to get a transaction through your site?
Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.
He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.
In Part 2 of his series, Tom asks:
If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].
This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video.
[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]
Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:
and turned it into an art (and science) form that allows people to create things like this:
And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.
The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:
- 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
- modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
- For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees & a2+a4+a6… = 180 degrees.
- No self-intersection at overlaps – a sheet when folded cannot penetrate itself
[Note: if you don’t understand these rules, watch the video. ]
Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)
Lang discusses that as well, and provides this diagram:
In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.
Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.
And finally the base form can be refined to create the finished model. That’s fairly straight forward.
The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.
What does this have to do with product requirements and Tom’s question?
When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.
- Product Managers investigate real world problems, needs, scenarios etc. (Subject).
- They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
- These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
- The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).
Sounds pretty good so far right?
But herein lie the problems, because that “hard” step in origami, is REALLY hard in product development.
- There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
- Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
- Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
- In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment. In the origami situation, this would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
- There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.
This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.
i.e. users of this product must feel giddy with excitement the first time they use this software
So, can origami teach us something about product requirements?
Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.
Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.
There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.
But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.
So, thanks to all of you who voted for us in the Canadian Blog Awards.
We didn’t win. We didn’t come 2nd or 3rd. We came in 4th in our category, just ahead of some dude named Matt Scott Nelson.
So, perhaps next year? At least this year we made to the final round of voting.
Thanks for your support.
Please take 5 minutes and help with the research. The survey is mercifully short and applicable to virtually every one of you.
Here’s the URL:
If you want to see the final results, you can provide your email at the end of the survey.
Also, please pass the URL onward to your friends and colleagues and ask them to fill it out and do the same.
Voting closes soon so vote now.
It’ll take 5 seconds. You’ll feel great after voting. We promise.
|Here’s the link. —–>> CLICK HERE <<——|
Please vote now.