Product Design Part 2: Iterative deliverables

Conventionally, product requirements are gathered by soliciting users for requirements. If the user is solicited for requirements, he will only be able to come up with some imaginative thoughts, but those might not necessarily be his real requirements.

Instead, give user a pilot product to use. Now you may ask how do you come up with a pilot product. Its a catch-22. Here is where you will be creating your differentiation or creating a new market altogether. You have to become a keen observer of the problem that you are trying to solve. Once you have intricate knowledge of the problem space, you can start to answer that by your pilot product. It is this pilot product that you provide to your users. Once the user has a tangible pilot product to play with, he will be able to point out shortcomings. Real requirements will only surface when he will be provided something tangible to play with. Here you should tap into the basic nature of us humans and that is we are experts at pointing out negatives in any walks of life. Give the user your prototype product, and he will easily be able to come up with a laundry list of shortcomings in your product. These shortcomings are your product's real requirements.

Thoughts on Product Design

In coming weeks, I'll be writing a series of blog postings on the topic of 'product design'. Being in software industry for almost a decade now, I have come across software products fitting in the range from 'mediocre' to 'blow your mind' kind of products. I've also have avid interest and keen eye on design for non-software products too. I have always liked to import ingenious design ideas and get inspiration from them to apply it in the context of my work. I also like to debug the design thought process that goes behind great products. I'll be sharing my insights from such experiences in weeks ahead. Below is the first of ten part series of postings that I have planned.

Product Design Part 1: Keep Context in Mind. Let bigger picture define the smaller picture.

Let me ask you a simple question about designing a chair for kids in age group of 2-4 years. Should a kid's chair be designed to bear 50lbs or 200lbs? And no, I am not referring to designing chairs for obese kids who are weighing 200 lbs. This question is purely from a design standpoint taking into consideration the context in which the product, in this case - the chair, will be used. The logical answer to this question is a kid's chair should be able to bear about 50 lbs of weight because a kid of age 2-4 years would normally weigh in that range. But, if you take a step back, and see the usage of the chair in a bigger context, the answer would be 200lbs. Let me explain why. If you question the overall context in which the chair would be used, you would discover that the kids chair will not only be used by the kid himself. It would most likely also be used by an accompanying adult (parent, teacher, elder sibling). It would be inconvenient for the accompanying adult if the chair was not able to bear his weight. He would be either forced to kneel down to bring him to the level of the kid who is sitting on the chair, or bend from waist down. On the other hand, if the kid's chair was designed so that it could also bear the weight of an adult, it would make it so much more convenient. Had the context not been considered, the chair would not be able to deliver a 'wow' experience for an adult user.

While designing products, be it a kid's chair or enterprise software or whatever you are designing, it is necessary to extract the design requirements keeping the bigger picture in context. Context not only guides you to extract 'practical' design requirements, but it also protects you from feature creep. Any and every feature of the product has to make sense in the context of the bigger picture, the bigger context. Context helps you uncover features of the product that otherwise might not have been discovered with conventional way of thinking. This is as shown in the example of the designing kid's chair. Conventionally, a kid's chair would not have been designed to bear 200 lbs of weight. Only when you consider context, do you uncover such requirements. And it is such requirements that go into making products that deliver 'wow' experience to your dear customers.

Is it just me or do you think that wikipedia could use better presentation of information?

Don't get me wrong. I am a big fan of wikipedia. I treat it as a good source of information, and hang out frequently devouring information on pages after pages on wikipedia. However, after reading some number of pages, it just starts to drag. Again, don't get me wrong. The information is wonderful, but the presentation needs some work. I can't tell exactly what is wrong. Maybe using a different font or maybe line spacing or maybe page layout might make the difference. Maybe all the pages have too many links and these links are blue and are underlined, which starts to hurt the eyes after some reading. I cannot precisely pinpoint what's wrong in the presentation of pages, but all I can tell that there's something missing.

In general, that's something I've always felt about software applications. Great applications have features that you won't even notice because such features just gel naturally with usability. However, when such features are absent, its just hard to define them. I guess that's what separates good applications from great ones.

Example:
1. In the browser, you use CTRL-F to find text on a webpage. In Internet Explorer, CTRL-F opens up a dialog box. You have to keep juggling this find dialog box as you search for the text on the webpage. In Firefox, CTRL-F makes search textfield and related buttons viewable at the bottom of the browser window which is just so convenient. Moreover, as you type the text in the search textfield, it changes background color of the textfield to red if it cannot find the text, or green if it can.

Microsoft's Photosynth: Beauty lies in the eyes of your computer

From blogging standards, it ridiculously late to post about Microsoft's Photosynth technology. Its way too old news. But somehow, in the act of serendipity, I came across it recently, and was completely blown away with where this technology can take us. I am sure you will be blown away too. Wait until 4:05 minute into the video, where Blaise Aguera, chief architect of Photosynth, shows how a 3D image of the Notre Dame Cathedral that was reconstructed just using the pictures of it on flickr. You can also visit http://labs.live.com/photosynth/ for a web version that is shown in the video.


If you are short of time, scroll to 4:05 minute mark to see the 3D image of Notre Dame Cathedral.

Customer service phone call - an opportunity to 'humanize' your business

Companies are becoming more and more inhuman when it comes to customer service support phone calls. They make the customer feel stupid by making them talk to their voice recognition software, and making their dear customer answer questions repeatedly until a robot correctly understands what is being said. Imagine the embarrassment when calling customer service while you are in a public place where there is a possibility of others overhearing you say 'internet connection down.....internet connection down' endless number of times in different accents just so that the voice recognition software understands what you are saying. Why do businesses today want to embarrass their customers. All this does is just create ill-feeling towards the company. Reducing the cost of customer support by using voice recognition software to automate tasks is a good idea, but is it really worth it when what it exactly does is create ill-feeling towards your business.

Instead, customer support call is a great opportunity to 'humanize' your business. Its a great opportunity to present a human side of your business. In case you have screwed up and your customers are calling you for that, its a great opportunity to let them talk to a live person who would be able to convey more humanly (and emotionally too) that you are aware of the issue and are trying your best to fix it. Customers wouldn't mind screw ups so much if they are assured that they are being worked on and will be fixed soon. Humanizing your business will create empathy towards your business in the hearts of your customer. It will only create more loyal customers. Imagine how ecstatic your customers would feel because they got a chance to talk to a live person straight away, when they were anticipating pressing numbers for different menu options or clearing their throat for preparing to speak to a voice recognition software.

When it comes to putting your customer service on steroids, following comes to my mind:
1. Have a front line of customer service representatives (and lots of them) just for triaging the call. This would give the impression to the customer that they had a chance to talk to a a live person right away. After this initial welcome and triaging of the call by a real human, it would make it less painful to wait on hold. Also since the call would be triaged by a human, it would be more routed correctly to related second-level of representative.

2. To make #1 even better, instead of putting customer on hold after triaging the call (by a real human), get a callback number from the customer and tell them you will call back in certain amount of time. This would free up the customer who would gladly accept the incoming call later from your customer service department.

Do the above options really cost companies too much when weighed in the loyal customers it would bring in. Would it really cost companies too much when weighed in the fact that happy customers will evangelize their business bringing in even more new customers. Is squeezing cost on customer service really a good idea? Instead, humanize your business and provide more humans on other side of the phone when your customers call in. All your customers want is to talk to a human instead of pressing number for endless menu options and repeatedly saying something which your voice recognition prompts them to say.

Amazon.com: Wish it had 'Wish Price' for items in 'Wish List'

For every product, there is a customer at a given price. 80GB iPod may retail at $333. Definitely, there will be customers living on cutting edge and are willing to pay that price. However, there will be many more potential buyers for the same iPod at say $250, and even more buyers at $200. Increase in sales volume can help bring down the price. Also, with consumer electronics product, price also decreases with time, at which point buyers who have waited to buy at lower prices will jump in. Currently, a large subset of consumers are willing to wait out for prices to fall over a period of time at which point it becomes affordable for them.

Instead of price being a function of time, price can still be shrinked by increasing volume. Increasing volume means aggregating more buyers to buy a particular product. Which better place to aggregate buyers than Amazon.com. Similar to 'Wish List', Amazon can introduce 'Wish Price' where users can specify their willingness to buy a particular product at a given price. 'Wish price' is the price users 'wish' the price was at which they are willing to buy the product.

Amazon can perfectly orchestrate such buyer aggregation (demand aggregation). It already has wish list of millions of Amazon users. All they have to do is add another 'Wish Price' dimension for items listed in customer's 'Wish List'. Once, Amazon is aware of this Wish Price, it can very well orchestrate the demand to subsidize the price. This way, Amazon would have shrunk the time by aggregating more demand, leading to lower prices.

Self-disrupt to Avoid Self-destruction

For sustained success in business of software, it is necessary to constantly anticipate next curve. Not only anticipate, but execute to make the jump to the next curve early on. But often, incumbents become victims to innovator's dilemma (book reference: Innovator's Dilemma) and fear to self-disrupt and in the process get self-destructed. They don't want to strangle their current roadmap that is bringing in revenue. And, surely, they don't want to upset Wall Street.

However, Apple is one of the organization that is self-disrupting in the space of consumer electronics. Apple's iPhone is a good example of self-disruption. Apple's iPhone is an early indicator of self-disruption of its very own product - iPod - that won Apple back its lost glory. iPhone will eventually replace iPod. This might not happen this year or next, but in future not far away from today.

For any organization, big or small, self-disruption should be a built in trait to maintain long term leadership in its business. They can do so in following ways:
1. By having next generation of themselves (a different business unit or a spin-off), whose sole responsibility is to attain leadership on the next curve. In doing so, they might and should take away revenues from their parent company who is still a leader on older curve. This way the parent company will lose its market share, but only to the next generation of itself.

2. Other approach to self-disruption is to acquire company(s) who are already on the next curve. Even though this seems to be dull and not-so-challenging approach as compared to #1, it is a practical one. Instead of placing bets and investment on next curve, its definitely better to shop-and-compare for proven companies who are on their way to become leaders on the next curve. Such an acquistion approach also works out well for software business ecosystem. Smaller startups can innovate at a greater velocity than bigger organizations. Bigger organizations, on other hand, get to shop-compare-buy and not risk their investments based on speculation of next curve. Also, after certain stage, smaller startups can flourish better under big banner organization by taking advantage of its branding, sales, marketing, customer support and other infrastructure.