Customer Centric v Operationally Efficient

Two months back I had written about automated e-mail responses for service tickets versus custom messages. The argument was automated = conversing with a robot while custom = conversing with a human. Human conversations allow the latitude of slipping in greater related information than robotic messages do and hence are more effective in establishing that emotional bridge with the customer.

I was pleasantly surprised when I read what Joel Spolsky practices at Fog Creek. Here is an excerpt from his post at

For example, we usually reply to a customer complaint with an e-mail that includes a discount offer on the purchase of another product. But rather than automate the message, we have opted instead to create a written template that staff members have to manually cut and paste into the body of an e-mail.

They are encouraged to edit the text to suit the circumstances, which forces them to take a little extra time and think a little bit harder about whether they’re saying the exact right thing to this particular customer. They can make the text more familiar if they know the person well or more apologetic if we really screwed up. They can also take the coupon code from the template and process the discount for the customer right away, if they are talking on the phone or over IM.

The objective is to make our customers feel as if they are having a real human interaction — that they are not just dealing with cogs in a big machine. As a smaller entrepreneurial company, we have this luxury, and we exploit it.

A large company may not have the “luxury” that Spolsky speaks about and I sometimes wonder why. The “large company” possibly made a wrong choice when faced with “operational efficiency” and “customer centricity”.

Technorati Tags: , ,

Poorly Researched Posts

I wrote two poorly researched posts in my blog sometime back.

  1. In this post, I wondered why digital cameras did not strive to complete the user workflow of uploading photographs by allowing internet connectivity through the device. Panasonic Lumix TZ50 has it. Engadget did a preview in January of this year as well.
  2. My colleague Srinivas Nivarty kept me honest by pointing out the following as a reply to this post where I wonder why the end user license of an e-book should prohibit “reading aloud”.

I think the ‘reading aloud’ bit refers to text-to-speech tools being disabled. Adobe Reader usually allows PDF content to be streamed as voice and this feature is possibly restricted in this ebook.

Ctrl+shift+b – to hear the entire Document
Ctrl+shift+v – to hear the page
Ctrl+shift+c – to resume
Ctrl+shift+e – to stop

A little knowledge is indeed a dangerous thing. I promise to research better in the future.

Let them Drive. Not Dictate.

Let customers drive your product road-map – let them not dictate it. I have witnessed both sides of this divide. A strong product management team invariably has strong, unambiguous and pragmatic product road-maps. When these are taken and presented to customers and prospects they understand. They feel reassured that there are smart minds taking care of the future of products they have bought or are contemplating to buy. They accept your argument even if they are not entirely happy with it.

Then they are iffy product road-maps. These are nebulously defined, self contradictory and are either terribly grandiose or pathetically unimaginative and can be seen through immediately. Customers sense the despondence and move in to become surrogate product managers. All hell breaks lose and the product road map is first hijacked and later bombed away by a combination of lack of consensus, impracticality of implementation and rudderless thought leadership.

It is a misconception that product road-maps will automatically emerge if they are left to customers entirely. Customers want to get along with their jobs as they expect the product manager to get along with his.

Post Script: I recently came across a product road-map presentation that had this disclaimer – “brave propositions have been made in this document”. Brave? Or did the author mean Foolhardy?

Technorati Tags: , ,

“Goog” – A unit of Plagiarism

It was a website, a service, that allowed registered users to create sub-websites (if I can use that term). A sub web-site was typically on a topic you would want to show your expertise on (or initiate/provoke a debate, for that matter). One could create as many sub-website as one pleased as long as the name wasn’t taken by someone else. The service is called Squidoo started by Megan Casey and Seth Godin. Squidoo just provides the service and the content, called “lenses”, is built by users. This is the great appeal of Web 2.0 and Squidoo was almost the Holy Grail.

A couple of days back Google put “knol” on public beta. Knol, purported to represent “an unit of knowledge”, is nothing more than a plagiarised version of Squidoo. Original thinking is briefly left Gooleplex. Product Managers are having it easy. Search cyberspace for interesting services (the blogosphere generally is a great place to start) and make a shortlist of those that can be launched with minimal investment and leveraging existing assets.

When was the last time something completely original and breathtakingly interesting came from Google?

Technorati Tags: , , ,

Workflow. Optimization v Cannibalization

Workflow based products strive their best to help users complete the workflow. Embedded in this rather simplistic statement is the basic premise of selecting the user interaction, functionality and features of the workflow product, which can be as much a device as an application. For example,

Microsoft Word features the functionality to complete the workflow of sending out the document as e-mail without having to exit the application and fire up the e-mail client.

Take a closer look at business handheld-telephone devices. Almost all (I am chained – literally – to the Blackberry) provide functionality of saving received-call numbers, making notes during a call, checking e-mail archives and such other workflow completion features within the device. For a product manager to design the application with the intention to close the workflow loop, she must understand what the workflow is. And more importantly, what part of the upstream and downstream workflow does the application (or device) support.

This is where I cannot understand digital cameras – more specifically why mobile telephones are trying to become cameras, thereby tying users down to telecom service providers. It is possible today to take a picture using a mobile telephone and e-mail/MMS that using pipes provided by the telecom company. The charges for doing this is exorbitant because the pipes are optimize for voice, not so much for data. Also, it stumps me why users would repeatedly perform such battery gulping acts on their phones, leaving them vulnerable to a situation where a drained battery stares down when an SOS call must be made.

Digital cameras, on the other hand, suffer from the stark absence of workflow completion. We all take pictures and then transfer them to our PC/Mac using a cable and then e-mail them to friend and family or upload them to online albums. This begs the question – why does the phone attempt to complete a resource draining operation that I am not even sure is the workflow while the camera doesn’t. Building Wi-Fi capabilities in the camera would not only allow as-it-happens photo sharing at a cheaper price but will also pave the way for better photo journalism. No – I am not asking digital cameras to become PDAs.

Workflow optimization and workflow cannibalization is very thin line and it is important for Product Managers to understand both.

Technorati Tags: , , , , ,

Back or Front?

Be nimble, start small, get traction, generate revenues, (then profits), IPO, face analyst stares, get sold to Banker’s non-organic growth pitch, acquire companies, bloat, lose nimbleness. There are only a handful – if not a fingerful – of companies that can force themselves out of this vicious circle of life for start-up companies. Acquisitions happen.

And once they do, the pressure to integrate acquired product assets with the core offering becomes of paramount importance (after all, synergy was why the acquisition was made, right?). There are two approaches to integration that I have seen corporation take. First option – integrate the front ends of the two system. That is, figure out the common platform and slap screens (all or select) of the other into it. The back-end infrastructure and databases that feed the two systems can stay different or perhaps just loosely coupled. Second option – create a cleaner integration of the back-end systems and infrastructure that ensures cleaner plumbing. The front-ends can stay separate and will come together when their feeding systems have gotten sorted out.

Both these options are acceptable but if someone stuck a gun to my head I’ll choose the first option. Here’s why

  1. Customers want to see benefit from the acquisition, and they should see it in the front end of the product. Customers want to experience the acquisition, touch it, feel it. They deserve it too.
  2. Back-end plumbing is a relatively easier problem to solve. One can throw people at the problem – perhaps at low-cost-centers or outsource to maintenance vendors. And once the front ends have been integrated, the pressure from business to clean up the rear (no puns, please) will ensure quicker compliance (especially if data center problems are breaking the front ends)
  3. The front ends coming together opens up possibilities for users to leverage the combined offering and in doing that they will figure out interesting ways of extracting synergies that the Bankers who came to make the acquisition pitch never figured out. That’s what every product manager lives for.

There is one large, hairy matter that can definitely break this choice. Usability. At no cost should user experience be compromised when screens are mashed together at the front end. It is undeniable that there will be changes in navigation, but that should never compromise on ease of use or continuity of functionality. Gopal Shenoy, who writes a popular blog on Product Management, has an interesting example to cite.

Technorati Tags: , , , ,

Product Usage and End User Licensing

This is how Wikipedia describes an End-User Agreement, typically for a software product

“Some end-user license agreements accompany shrink wrapped software that is presented to a user sometimes on paper or more usually electronically, during the installation procedure. The user has the choice of accepting or rejecting the agreement, without reading it first. The installation of the software is conditional to the user accepting the agreement and thereby agreeing to abide by its terms. Once the user has installed the software, then he/she has the opportunity to read the license agreement in detail.”

Creating an end-user agreement or contract poses challenges that go beyond that of creative legalese. One such that plagues the industry I am currently in (financial information and decision support) is that of restrictions on usage. Simply, this is where the creator-seller of the software product is trying to ensure that her revenue stream is protected by the terms of the contract and she is not giving plenty free in the way the contract is written. Consider this hypothetical example

Google wants to monetize its search business by charging users for searching. The firm has two options. One, charge for every search string the user executes. Two, charge a flat rate per license per month to access Both the options have their pros and cons. If the product is inferior (google search is not, but you get the point) option one will slow-bleed the product to death. If the product rocks, the second option will leave a lot of money on the table.

Interestingly, the second option is what in the financial information business is called “kiosking”. Under that option, the buyer can opt for Option Two above to buy one license and put it out on a public computer in the library for people to come and execute searches (yes, there will be a pretty long queue at the library but the buyer saves a lot of money). In one stroke, an annuity revenue stream has been kiosk-ed into a lump-sum license fee.

Putting the legal aspects of licensing aside, it is not trivial to find out the correct usage situations of the product to weave them in the way the commercials are structured. And it is not a bad idea to think about this as a product is being built out.

Funnily, I came across this example of a ridiculous end-user “agreement”. It prevents the user from reading aloud an e-book! Brings me to my final point. Iron-cladding the end-user license is great but please ensure your firm can audit the compliance.

Technorati Tags: , , , , ,