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 Inc.com

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: Customer e-mail, customer centric, customer service

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: Product Roadmap, good Product roadmap, defining product features

“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: Plagiarizing features, Squidoo, Google, Knol

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: Workflow, Close Loop, Workflow Optimization, Digital Camera, Mobile Phone, Wi-Fi

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 Integration, Front end components, back end databases, Usability, Product Acquisition

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 google.com. 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: shrink wrapped software, end user agreement, product usage, product pricing, kiosking, product pricing models

Work+Social Media+Networking = A False Promise

Workstreamr held the equating promise of Work + Social Media + Networking = Workstreamr. A fairly enticing concoction that most people will struggle to pass up. At least I could not.

The sign-up page was simple in design but it had a question that I had never encountered for any public beta service (underlined in red) in the past

I wrote out a response and then waited with baited breath – much alike someone who has just written an examination – for the invite to arrive. It did.

I am a VIP in their books – or so they said and they will most likely launch in June. Good. It’s the fifteenth of July today, by the way.

False features and false promises are equally lethal for a Product Manager.

Technorati Tags: Workstreamr, Public Beta, False Promise from Product

Challenges of Off-Shored Product Management

In 2004 I started off “offshored Product Management” for Thomson Financial (TF) in Bangalore. It was a brave move by TF to plunge into a territory that no other firm had shown valor to. In complete honesty, I did not fully realize the nature of the beast – “offshored Product Management” – until I saw it in the fighting pit. There were several differences in this form and traditional Product Management, a world I came from

1. (Somewhat) unidirectional: If one thinks of Product Management as Janus looking at two directions, then this version looks mostly inwards. That is, the focus of off-shored Product Management is emphatically more on definition and ruthless control on execution and quality
2. Degree of separation: In an earlier post, I had written about dis-intermediation between the product manager and the end-user community. In off-shored product management this is a reality – a bad one but sadly on that cannot be wished away. It is not unnatural for off-shored product managers to have had no contact with users. Sometimes contact happens only when something breaks down real bad. The problem is solvable, but should not be made a sine qua non – has the potential to completely jettison the off-shoring of Product Management plans by the parent
3. Layers of complexity: Building software products is not an easy task. In off-shored Product Management, the matter is further complicated due to geographic (read time-zone) dispersion of different arms of the organization that are expected to act in unision of build a product. Business pragmatists would avoid this pitfall while setting up the off-shoring model but common sense – as we all know – isn’t that common.
4. Abrupt ending: Product Management is a neat loop. A loop that starts with the customer and ends with the customer, touching all the internal functions in between. Unfortunately this is difficult to replicate in off-shored Product Management because of #1 above. Product Managers experience an abrupt end in the cycle and often depend on sales and commercial managers to loop in the feedback with which they embark upon their next release. Chinese Wishper flourishes rampantly.

These challenges are definitely not exhaustive and can have firm-specific manifestations. The trick in managing these challenges is to use a framework to define which products are more amenable for off-shored Product Management on the face of these listed challenges. Some organizations fall into a rather predictable trap of establishing CMM (or equivalent) processes off-shore to overcome the difficulties. That is incorrect since it is not natural – one arm of an organization trying to establish a process that the other arm doesn’t want to sign up on. It just causes more friction and eventual (and painful) demise of off-shored Product Management.

Post Script: Captive firms (i.e. wholly owned off-shored arms of parent companies) face a lot of headwind in operations. While these differ from pure-services offshored plays (like Helpdesk or Accounting off-shoring) to more higher end off-shoring (like Product Development) here is a nice post from Basab Pradhan that takes a deeper dive.

Technorati Tags: Off Shored Product Management, Off Shored Product Development, Challenges of off shoring

On-the-face bad news? Good.

Outdoor media displays like the one below are commonplace in Stockholm, Sweden

Got me thinking…I am the Product Manager for a web based financial information and decision support system. Would I dare to place a screen in the reception area that

1. Shows number of subscription cancels for the year
2. Shows cumulative system downtime for the quarter
3. Shows a count of bugs in the last release and cumulative to-date

Yes, this is terribly on-the-face and that too with bad-news. But bad news happen. Good product managers keep a tab on the negative as much as they do on the successes. The sales team are often given gross revenue targets but the product manager’s concern is on the net numbers.

Even if you don’t have the counters at the reception, you should (must) have it in your mail box every week.

Technorati Tags: Product Metrics, Bad News, Product Management