Showing posts with label product management. Show all posts
Showing posts with label product management. Show all posts

Friday, February 27, 2009

Facebook, smacked down again, invites customer input

Facebook always does the right thing by their customers... once their customers have beaten them up for a wrong first step. A year and a half ago they stirred up the wrath of their community by proposing an ad-targeting system leveraging its users' profile data, then backed down.

Now they've done it again. Facebook changed their terms of service, igniting another storm of outrage on blogs, Twitter and, yes, Facebook. They relented, returning to their prior terms of service, and yesterday announced that they will be seeking user input on community questions such as terms of service, and be more transparent, including this statement:

Transparent Process: “Facebook should publicly make available information about its purpose, plans, policies, and operations. Facebook should have a town hall process of notice and comment and a system of voting to encourage input and discourse on amendments to these Principles or to the Rights and Responsibilities.”

It's easy to make fun of Facebook for their public embarrassments, but they do get the message their users are sending. Furthermore, they are pioneers in engaging with their users. There is no template they can follow. Facebook's users, because they give personal and sensitive information to the service, is very sensitive to its use, and the web2.0 nature of Facebook means that its users are comfortable using web2.0 means to communicate. Quiet they are not.

It will be fascinating to see how more traditional companies deal with assertive user bases. As consumers find their voices on line (and efforts like VRM give users powerful tools to manage and communicate with their vendors), we'll be reading more stories like this one. Will other companies learn from Facebook's painful lessons?

Related post:
Zuckerberg learns

Monday, January 26, 2009

Customers are talking: the Blackberry Storm/Twitter project

Like a lot of people, I've been trying to get a handle on what Twitter means for businesses. My professional interest is in finding unsolicited customer stories and making sense of them--wherever they are. In this, Twitter has a lot of promise. It's easy to use, brief and spontaneous. So are customers using this forum to talk about products? I decided to find out.

My test case was the Blackberry Storm. It received an absolutely terrible review from David Pogue, the New York Times' consumer-electronics columnist. It also had very good early sales numbers--500,000 units the first month of its release, according to the Wall Street Journal. The combination of these made it an irresistible subject to study: would the Twittersphere be flooded with posts from enraged buyers?

The project was made more interesting today, when the Wall Street Journal published an article entitled, "Bumpy Start for Blackberry Storm," which referred to complaints of early Storm users (but not Pogue's review), including this vibrant quote: "I found myself wanting to throw it in the ocean due to my frustration with its overall usability." The article also referred to a release of firmware soon after launch intended to address some of the early complaints, particularly response time.

I used Twitter Search to look for messages containing "Blackberry Storm" and a happy or sad emoticon (there's a button on the advanced search page that enables you to restrict searches this way). I looked at 88 English-language tweets going back to December 27. Here's what I found:



The biggest surprise to me was: where were the complaints from users? While half the Tweets were from Storm users, as opposed to people commenting on the Storm, or thinking about it, only 4 out of 44 (9%) of the users' tweets were negative, while 23 (52%) were positive.

(If you want to check out the searches I created for this project, they are here: happy search, sad search. Twitter Search has been acting funny the past few days--I'm only able to get one page of recent results, and can't search farther back. I used an RSS feed of the search over a period of weeks to gather the entire list of 88,)

From a customers are talking perspective, this isn't a terrible outcome at all for the Storm. Whether the firmware change made that much difference, or the Blackberry brand loyalists are immune to hardware glitches, or simply that devices like this aren't perfect and users expect that--they are not saying this is a terrible device. Many are saying that they like it. If I'm Blackberry and Verizon, I'm not discouraged by the Storm's initial reception.

By the way, the WSJ has already started to backtrack. On the web site, the article is now entitled, "Blackberry Storm Is Off To A Bit of a Bumpy Start."

(Disclosure, I am a Verizon customer and a Blackberry 8830 user. If you think I am a shill for Verizon, please don't make up your mind until you read this post, or this one.)

Wednesday, January 21, 2009

Customers are talking: The Eureka Button


I was talking to Cynthia Kurtz once and she mentioned, "If I were developing a piece of software I would always want to put a Eureka Button on every page."

A Eureka button is this: if while using the system a user just figured something out that others might benefit from, he/she would click the button and be presented with a page where she could enter:

What Happened?

Where does this apply?

When should people read this story?

This input and information about where they were in the system (page & data) would be uploaded to a database. The database can be searched for patterns or browsed periodically, looking for bugs or unexpected uses of the system.

It's easiest for me to think about the Eureka Button in the context of enterprise software. Having worked a lot with CRM systems for telephony, I know that these systems have hundreds of user pages, with a virtually infinite number of paths through the system.

In these environments, product managers may know in theory how people should use the system. But their knowledge is quickly overtaken by experienced users, who learn how to apply the system to their jobs, often finding tricks or shortcuts to make the system work better for them. ("Eureka! I just figured out that if I dummy out some data items, I can capture information & save information from a prospect before they decide to make a product purchase. If they call back, I can look them up by their phone # and I don't have to start all over again.")

In this situation, a Eureka Button has great value for the product manager and the users. Product managers can learn about difficulties users have and how they overcome them. The tricks can be incorporated into the product, or deficiencies addressed. Users can learn from each other--perhaps Eureka Button entries can be blogged automatically and read by other users, dispersing tips and tricks and encouraging others to share their stories.

I can't even begin to catalog how a Eureka Button could benefit consumer sites, where (especially recent) products follow an emergent, iterative development approach and patterns of usage can affect the entire purpose of the product (e.g., Twitter). There are people much better suited than I to discuss some of these implications. If you're one of them, please let us know in the comments how the Eureka button could be used with these products.

(In searching for prior references to a "Eureka Button," I discovered this NY Times article from 2004. The article mentions that "'It's amazing how many people there are who find pleasure in sharing the little discoveries they make.'" The article focuses on undocumented features in PC software and in consumer electronics. The article references a site that publishes user stories of hidden Windows features.)

Monday, January 05, 2009

Why you should listen to customers even if they're wrong

You should listen to customers even if they're wrong
Even companies who believe "the customer is always right," if there are very many of them left, don't mean it literally. They mean something like, "We try to accomodate the customer, even when they are wrong." But beyond addressing the immediate symptom (the heart of "the customer is always right" philosophy), there are valid reasons why you shouldn't dismiss (or disregard) customer stories that you don't consider accurate:

1. There is truth in their perceptions, even if the facts don't add up. Customer outcry is emotional, not logical, in nature. If they complain, they are feeling pain, and even if they can't articulate the reasons to your satisfaction, the root issue is very likely significant to you.

2. Customers have more credibility than companies. Recently, in my town, there's been a conflict between the private water provider and the town government over a proposal to raise water pressure and whether that might be causing an increase in water main breaks. In an "open letter" to customers, the regional president of the utility tried to dismiss criticism of the program. Who was more credible to town residents: the elected town representatives, or a water company regional president?

3. Being factually correct is overrated. In marketing, perception is reality. Brand is an accumulation of perceptions. Jochum Stienstra discussed in a recent post how those perceptions create a profound, cognitive reality for customers. So, in focusing on the data and dismissing the perceptions, you may be missing the point.

4. They may, in fact, be right :)

Thursday, December 04, 2008

Example of a blog attracting user stories

Sorry for this somewhat awkward syntax of this post. I am composing it on my Blackberry 8830. This is significant because the post concerns David Pogue's eviscerating review of the new touchscreen Blackberry Storm mobile phone.

In response to the review, Pogue received more than 100 stories of people who also hated their newly-bought Storm. There were also dozens of defenses of the Storm and RIM, its maker. And many more comments in response to the post.

Pogue's post served as an attractor, stimulating all sorts of vibrant customer feedback. As a product manager and someone interested in innovation, this example is fascinating and illustrative of how social computing is revolutionizing market & customer intelligence.

What does all the feedback mean? Probably lots of things: the Storm has serious issues; RIM has committed, passionate users; Apple is a hard act to follow, etc.

Whatever it means, let's hope that RIM is listening, sensemaking, and acting. If they want some guidance, tell them to shoot me an email.

By the way, composing this post on the 8830's thumb keyboard & tiny screen has been agonizing. I was hoping the Storm might be my next step. Now I'm not so sure.

, , , , ,

Wednesday, November 05, 2008

Innovation made easy... or else

Many of my posts originate when two interesting ideas collide--two things I've read, possibly from very different points of view or with different objectives in mind, somehow fit together, or together illuminate something to me that's clearer than either piece on its own.

Today there are three such things. Let's call them stories of innovation made easy. First is the paper "The Ergonomics of Innovation," by Bob Sutton and Hayagreeva Rao in September's McKinsey Quarterly, which despite its awkward title is very clearly written and argued. Its central point, illustrated by the Institute for Healthcare Improvement's campaign to save 100,000 unnecessary hospital deaths, is that the best innovations are often the simplest and most basic. In other words, a partial solution that is easy to communicate and to implement may bring far more value than a more complete solution that is more complex and difficult to bring into production. Here's a synopsis of Sutton's and Rao's argument:

A basic idea from ergonomics is that physical and cognitive “affordances” can help people to think about, know, and use something more easily and to make fewer errors. The IHI campaign didn’t use the language of ergonomics but nonetheless applied its logic in hundreds of ways by designing and spreading affordances that made it easier for the staffs of the participating hospitals to change.
I've meant to write about this article for several weeks. But two more things I've read this week buttressed Sutton's and Rao's arguments. First is a report from Mark Schneck at Anecdote on a talk from this year's ActKM Conference in Australia. This simple change didn't save 100,000 lives but may have saved 100,000 hours wasted reading emails:

Jane mentioned that one of the actions from their knowledge strategy has had a big impact. This simple action was for all staff to write a clear description in the subject line of their emails. Adopting this practice has helped staff deal with information overload by being able to quickly identify emails that they need to deal with, and which ones can be simply deleted.

Finally, today Andrew McAfee blogged about an innovation at American Airlines that simply isn't sticking:

According to American, "Customers with PriorityAccess privileges will be invited to board first or board at any time through their exclusive PriorityAAccess lane, which allows them to bypass lines after general boarding has begun." The new configuration seems to be pretty uniform; I’ve seen it at every airport I’ve flown out of over the past month, which is more than a couple.

The new configuration also seems to be uniformly ignored. My fellow travelers and I have continued to line up and board just as we always do, except now we use two narrow lanes instead of one broad one. I haven’t yet seen us fliers make any effort to sort ourselves into the ‘right’ lane, and I certainly haven’t seen anyone voluntarily take themselves out of the lane reserved for the elites and rejoin the general boarding hoi polloi.

More importantly, I also haven’t seen American’s gate agents make any effort to sort us properly. I’ve heard them make announcements about the two lanes, but that’s as far as it’s gone....

It struck me at some point over the past month that I was witnessing an excellent example of why so many business improvement efforts fail: it’s not that they’re not good ideas, it’s that they're not easy enough to enforce. American’s PriorityAAccess boarding procedure is a straightforward case of what used to be called ‘business process reengineering,’ and it’s also a microcosm of why reengineering so often failed. It’s one thing for a small group of smart people to study an existing process and figure out a way to execute it better. It’s quite another to then deploy that new-and-improved process broadly -- across many business units, geographies, and/or interdependent groups.

In other words, the PriorityAAcess procedure didn't provide enough affordances to allow harried gate agents to easily deploy it. So they didn't.

This is an important lesson for me. My automatic mindset seeks out the elegant, complete solution. I don't gravitate toward the simple, dumb solution. Even though, as I'm learning, that one may be the best of all.

(Bonus: this also reminded me of the previously blogged about innovation at a Singapore hospital, where a cheap webcam helped significantly reduce wait times in the emergency room.)

Related post:
Stop studying the problem, and just try something!

Tags:
, , , ,

Thursday, October 23, 2008

AG Lafley on P&G's innovation culture: "The consumer is boss"

In the newest issue of Booz & Co's "Strategy + Business," A.G. Lafley describes the innovation culture at his company, Procter & Gamble.

Hearing insights from Lafley and P&G about innovation is becoming a cliche, but this quote struck me as apt:


So we expanded our mission to in­clude the idea that “the consumer is boss.” In other words, the people who buy and use P&G products are valued not just for their money, but as a rich source of in­formation and direction. If we can develop better ways of learning from them — by listening to them, observing them in their daily lives, and even living with them — then our mission is more likely to succeed.

This what I'm thinking about much of the time now. How to help companies listen to, and learn from, "the bosses."

, , ,

Gathering customer product insight using Twitter

Gathering and sorting through customer feedback is an overlooked part of the product manager's toolbox. Currently-used methods are inadequate to the task: surveys are limiting and misleading (one man's 4 is another man's 3, and so forth). Focus groups are biased and prone to takeover by assertive voices.

Fine-grained, freeform feedback, such as is gathered in customer service calls (or, as I'm doing with one client, in open-ended interviews), provides a wide range of opinions from a diverse group, relatively untainted by outside influences, measurement bias and company hypotheses.

The new social applications offer a new and promising way to gather feedback cheaply and in real time. Twitter is one such application being put to use.

Dell and Comcast, for instance, troll Twitter looking for references to their products and services. If people are struggling, their Twitter users will reach out and try to solve the problem, or point them in the right direction to get help. It's as if a call to tech support was being worked on in public. It's highly responsive, and the users who get this kind of attention appreciate it, usually announcing their satisfaction in a Tweet.

Other times, Dell in particular responds quickly to critiques of their products (see an earlier post and a Dell comment). It's done well--not pushing back on the commenters, but certainly getting the company message out in that forum. In other words, comments on Dell products are always responded to.

Both the above examples have obvious PR benefits and bring the Comcast and Dell folks who engage in these conversations closer to the real customer experience. All good.

What I'm talking about, in addition to that, is collecting dozens or hundreds of tweets on a particular product and looking at them all together. What do they say about the product? Are these issues that seem to crop up continually? Are people using the product in unexpected ways? Is something about the product really, really annoying people?

Note that gathering the data is easy. Sorting it out is the hard part, but using narrative analysis techniques can separate the wheat from the chaff and give you real, useable insights.

(Here's an example of the Twitter conversation around the new Ford Flex. I hope Ford's product marketers are listening! Here's another conversation on the Flip video camera)

There are other ways to gather freeform customer feedback. Customer reviews on Amazon, for example. Blog posts. Companies should use all of them. Particularly as these technologies become more embedded, and more people start talking in these forums, the stories customers tell will be more and more vital to innovation and the product creation process.

(If you'd like a comprehensive look at how businesses can use social technologies to engage with the outside, read Groundswell by Charlene Li and Josh Bernoff)

Related posts:
Dell's web2.0 efforts pay off
Is Google listening to the stories around Knol?
On "Groundswell"

Tags:
, , ,

Tuesday, August 26, 2008

The power of "anecdotal evidence"

We have a bike rack on our 12-year-old Isuzu Trooper that fits into the trailer hitch. I mentioned to my wife the other day that perhaps next year we should add a hitch to our 6-year-old Acura MDX, so we can use the bike rack on the MDX after the Trooper gives out.

She laughed. "What if the Acura dies first?" she said.

My wife holds the perception very firmly that the Isuzu is a highly-reliable, trouble-free car, and that the Acura is a fragile thing, constantly in need of expensive maintenance.

Statistics say otherwise. JD Power gives Acura four stars for reliability (out of five), and Izusu only two stars--tied for the worst rating.

But looking beyond statistics, at the stories, the Trooper has a bunch of ardent fans. Some people have had terrible problems and hate the car, yet many others, a larger number, love it. (See this group of epinions posts for an example.)

And the MDX's reliability has some detractors as well (see reviews from Edmunds.com), with many complaints about transmission problems (writer crosses fingers).

What's most amazing is the firmness with which the reviewers--positive and negative--hold their opinions. It demonstrates the "tyranny of the mean," in which a lot is lost by averaging ratings together. A car is an emotion-laden product--expensive, used daily, inconvenience-causing when broken. Opinions then vary dramatically based on personal experience. The stories are arguably more important than the statistics when evaluating this type of product. And product managers, as well, should be especially attuned to the stories customers are telling about their products.

The lesson here is that "anecdotal evidence" should not so easily be dismissed, and that statistics can be useful but, just as when buying a car, you should look under the hood for yourself.

It might help you figure out why your wife thinks the old Izusu kicks the newer Acura's butt.

, , , ,

Tuesday, August 05, 2008

Is Google listening to the stories around Knol?

I talk a lot in this blog about how listening to stories can help companies take the pulse of users. When a new product is released, people try it out, and provide all sorts of information that's critical to the future evolution of the product. They don't provide this information in statistics, but in stories. If you can make sense of the stories, it can give you insight that you can use to make adjustments in functionality, customer service, technical support, pricing, and strategy (as discussed in the section on emergent strategy in "The Innovator's Guide to Growth").

Here's an example of what I mean. On July 23rd, Google released Knol, a product that collects and organizes "authoritative article[s] about a specific topic," according to the company.

Here are some blog stories that emerged after the launch:

knol: content w/out context, collaboration, capital, or coruscation
...We're quite a few months into the Knol experiment. What I find particularly fascinating is that most of the knols that they promote on their front page are health-related, primarily by people who claim to have health-related expertise (doctors, nurses, professors) who appear to be copying/pasting from other places. Why health? What's motivating these people to contribute? (And why are they too lazy to fix the formatting when they copy/paste from elsewhere?)

Frankly, from my POV, Knol looks like an abysmal failure. There's no life to the content. Already articles are being forgotten and left to rot, along with a lot of other web content. There's no common format or standards and there's a lot more crap than gems. The incentives are all wrong and what content is emerging is limited. The expert-centric elitism is intimidating to knowledgeable folks without letters after their names and there is little reason for those of us with letters to contribute. While I don't believe in the wisdom of a crowd of idiots, I do believe that collective creations tend to result in much better content than that which is created by an individual hermit. (Case in point: my *$#! dissertation vs. any article I've co-authored.)

What makes me most annoyed about Knol though is that it feels a bit icky. Wikipedia is a non-profit focused on creating a public good. Google is a for-profit entity with a lot of power in controlling where on the web people go. Knol content is produced by volunteers who contribute content for free so that Google can make money directly from ads and indirectly from search traffic. In return for ?... (full post here)

---

Knol for Google: It Is Not Evil, It Is Business
Google is a smart company - smart enough for many people to be surprised after they witness this or that move or an acquisition, surprised enough to say "Why has not anyone thought of that move earlier?" And now it seems that Google has finally realized that it sends way too much traffic from its search results pages to websites that do not contribute to Google's business. What would be the correct move for a business when faced by such a discovery? Find a way to make money by sending traffic to your own properties.

And this is exactly what Google needs Knol for: Google must be tired of being the major source of traffic for Wikipedia and many other independent publishers and now it looks for new ways to further monetize its own business. And for that it simply needed to have a platform of its own to be able to bring tons of content to internet users easily - and displace competitors from the search results. In this particular case Google serves as a full-cycle company: it provides the platform (Knol itself), the revenue (AdSense) and, finally, the distribution (search).

Sure, we hear lots of complaints about Knol already. It is quite obvious that from the day 1 of Knol launch we should have expected voices pointing at spam on Knol created in order to get revenue by building a page on a popular term. It was so obvious that it is almost ridiculous to complain about it now. The explanation here is that no matter what service people use they invariably are motivated by something. And often the motivation offered by the service determines exactly what type of users it will attract eventually... (full post here)

---

Knol – from Google blog
There is a debate about whether Knol is an attempt at competing with Wikipedia. In academic use, its unclear where exacly it fits - for example, much of what you would think of writing a "knol" about seems better placed in a standard journal article review or scholarly dictionary. Does this offer a replacement for those? Scholarpedia is another potential candidate for competing with standard academic review formats. At the moment, there is not much incentive for individual academics to produce these types of documents but is it, more generally, a more logical way of reviewing fields that are very fast-moving?... (full post here)

---

A Unit of What?
A knol, Knol says, is a “unit of knowledge”. I don’t think so. But I do think Knol is already becoming a den of spam.

My cursory research, at that link, suggests that the answer is yes. “Anemia“? No results. “Hair“? 12, including several (supposedly) by the top guy at the Beauty Network. “Cancer“? 38, so far, inncluding three in the first page of results for the biggest spam giveaway, Mesothelioma. Search for anything. Watch the results.

If this is about a fight with Wikipedia, I’d say it’s no contest. But it’s not. It’s about the corrupting influence of pure scammy ambition. Even if Google doesn’t have that, it plays host to plenty. And Knol (born on 23 July) was barely out of the womb before it got infected with it. (full post here)

---

The Invidious Knol
My third post on the subject and potentially the most worrying. This blog suggests that Google are tipping the search balance so that knols come above the Wikipedia on search. Its also got a good quote from Nick Carr I'm guessing that serving as the front door for a vast ad-less info-moshpit outfitted with open source search tools is not exactly the future that Google has in mind for itself. Enter Knol.

Now the evidence here is anecdotal, but it will be interesting to see if others carry out more scientific and controlled tests. If it is true then Google's famous Do Good, already tarnished for its willing to compromise its principles in China would be finally shot. It would be an interesting new form of monopoly and a major issue of trust. Any other evidence out there? (full post here)

---

Twitter is also a neat place for Knol micro-stories. Here are some:

I would suggest Google Knol. It is a combination of Squidoo and Wikipedia. Plus, it is SEO-ready.

admiring my knol, and blogging about Intranet Week and my new gig at J&J


the geekosphere hating knol out of gate only makes me that much more bullish on it longer term...


I love that the wikipedia article for Knol ranks above Knol itself. I wonder how long that will last?


google knol has boobies. Goodbye wikipedia!


Ready to pronounce knol a failure already? I think we'll see over time. Life is not *all* wisdom of crowds.


it's pretty cool that Google can afford to have full on projects that are pointless - and it doesn't really hurt - Knol, I'm looking at you


If I am Google, I am collecting every story I can find like this, and reading them all (including, and perhaps especially, the ones that are critical). There will be some randomness and noise, but with enough volume there will also be themes that emerge. Some that came out of my reading were:

- there's a feeling that Google will favor Knols in its search rankings, and that's a risk not only to the success of Knol, but also to AdSense, one of Google's cash cows.

- the commercial model for Knol, and the perception of can encourage spammers and risk degrading the content available via Knols, tarnishing all of them.

- the perception that Google is taking on Wikipedia (or "commercializing" it) is clashing with Google's "do no evil" mantra.

The Google team may find different patterns. Or they may not care to do anything about them. But they should at minimum understand them. Hopefully they're doing so. The changes that come in Knol over the next few months should provide some insight.

(To see the links for thirty-five stories found on the web about Knol, both blogs and tweets, click here.)

Related post:
Review of "The Innovator's Guide to Growth"
What in hell do stories have to do with innovation?

Tags:
, , , ,

Tuesday, July 22, 2008

What in hell do stories have to do with innovation?

Regular readers may be tiring of the constant barrage of story-related posts, or at minimum be trying to figure out how they relate to the title of this blog. Here are some words that I hope tie it together.

More and more products are launched and evolve in an iterative fashion. Version 1 does this, version 2 does that, and version 3 finally hits the mark and becomes the standard (exhibit A: Windows). Those iteration windows are becoming tighter, so good information as a basis of planning product changes is invaluable. Google in particular has turned this approach into an art form.

There are more and more ways to get feedback directly from users. Forums, call centers, social networks, Twitter, etc., etc., allow users to communicate their likes and dislikes about a product.

Now, to storytelling. Most business applications of storytelling focus on communicating outward--developing a story that helps communicate the essence or benefits of your product or company. Steve Denning, in his recent book "The Secret Language of Leadership" calls these indirect stories--stories that inspire stories in the mind of the reader or listener. Indirect stories are necessarily incomplete--they are not meant to immerse the listener in an experience (like, say, Harry Potter does). They are meant to create empathy and consensus.

What I'm talking about (as are Shawn Callahan & Mark Schenck of Anecdote, Dave Snowden of Cognitive Edge and others) is inverting that model.

In addition to crafting stories and sending them out toward customers, staff, etc., what if we listen to the indirect stories coming from them? They are also necessarily incomplete--mere anecdotes--but if you gather a few dozen, a few hundred, or a few thousand, common themes and threads will become evident. To invert Denning's language, there's the possibility of inspiring stories in the mind of the company.

These stories might say things like:

  • People find our product really hard to use.
  • Feature X of our product is proving more valuable than we expected.
  • A group of people are using our product in an interesting way that we didn't anticipate.

As a product manager, the above stories are very important to me. They help orient me toward things I should do to improve product packaging, add or delete features, alter its marketing message or improve its customer service or technical support. Also, the user stories are pre-hypothesis, meaning that they are free of bias that can come via hypothesis-based approaches such as surveys. They are not adulterated by groupthink, as can happen with focus groups. They are the voice of the customer.

None of the individual anecdotes may send clear messages about where innovation is working and where it isn't. But the accrual of them can do so.

Companies don't use this resource to improve innovation. They should.

And that's what I'm talking about.

(For a powerful example of the accrual of "indirect" stories to create a compelling, nuanced, overall story, please refer to this earlier post on Haruki Murakami's "Underground.")

Related Post:
Stories that people tell about products are invaluable

Tags:
, , , , , ,

Friday, June 13, 2008

Stories that people tell about products are invaluable

I was listening to a Dave Snowden talk today, and this bit jumped out:

We're capturing 150,000 stories a week from people as they consume a product. Because the stories that people tell as they have an experience are far more significant than customer satisfaction surveys.

Also this:

What people love... is numbers backed up by stories--numbers on their own, stories on their own have deficiencies. But numbers backed up by stories is quite powerful.

This idea--capturing & sorting stories from users to see how products are doing and how they can be improved--is something I've been messing with a bit, and it's good to hear that this isn't brand-new.

, , ,

Monday, March 24, 2008

Old technologies hang on for decades

What do radio, mainframe computers and photocopiers have in common?

They were all predicted to die a quick death at the hands of a successor technology, and all are still here today.

The New York Times profiles the venerable IBM mainframe, still a multi-billion-dollar business (not that any CIO would admit publicly to buying one), which has hung on through the minicomputer revolution (remember DEC?), the PC revolution and the client-server revolution.

According to the Times article, "survivor technologies" retain certain compelling benefits that the successors do not offer. Hence, for certain niches, they continue to provide value. For radio, it is the idea of "audio wallpaper," entertainment that's less distracting than video--i.e., good while driving or working. For the mainframe, it was the ability to retain billions of dollars of software investment while taking advantage of hardware's increased price-performance. Photocopiers offer easy-to-handle and share hardcopy documents that the paperless office can't provide. (I worked for a year without a copier and was that ever a pain.)

So consider this: the next time you read that a certain technology will be obsolete within five years, you may want to buy some stock in the dinosaur.

(Photo: an IBM mainframe that is likely no longer in service.)

, , ,

Thursday, December 20, 2007

A resurgent Kiwi helps redefine the shoe-care product category

I love stories of companies resuscitating old brands by creating innovative new products. It shows that "maturity" doesn't have to be the end of growth.

Today in the Wall Street Journal, a front page article by Julie Jargon discusses Kiwi, the ancient shoe-polish brand available in every drugstore (link - $$). When a new CEO, Brenda Barnes, was appointed to head Sara Lee, Kiwi's owner, in 2005, she looked to reinvigorate the company's growth.

The prescription was simple: Kiwi studied the market by asking customers what they needed from shoe products. (The most recent podcast, with Tony Ulwick, discussed how to get customers to tell you what they want.) Then they created products that matched what customers really wanted.

They learned: more focus on the inside of the shoe, its freshness, and less focus on polishing the outside. Presto! A line of new products, fresh packaging and merchandising, and an old brand beginning to grow again.

It's enough to make you want to check your closet for old shoes that need polishing up.

(Photo: Kiwi Fresh Force, "The only shoe freshener with a revolutionary upside-down application," courtesy of Kiwi)

, ,

Tuesday, November 27, 2007

Shop Talk Podcast #4 - Tony Ulwick on Determining What Customers Really Want from New Products

The podcast is back, this time featuring Tony Ulwick, author of the book "What Customers Want" and CEO of Strategyn, a consulting firm helping companies improve their innovation processes.

We're talking about how to gather information from customers to drive innovation. Most companies have "voice of the customer" programs, but few know how to extract quality information from those programs. It takes asking the right questions, and removing ambiguity from the answers. In the podcast, Tony states that it's wrong to assume that users can't tell us what they want; instead, the problem is that "companies don't know how to listen to customers."

You can access the podcast here.

Here are links to companies, people, etc., mentioned in the podcast:

Clayton Christensen - "focus on the job the user wants to get done"
Theodore Levitt's "Customers don't want a 1/4" drill"
Apple
Strategyn White Papers

, , , ,

Monday, November 26, 2007

IT Risk - platform and architecture matter

Once, in my days running sales and marketing for a software company, the VP of Technology was growing agitated with my complaints about our product's hardware and database architecture. "OK," he said in exasperation, "if you don't like [proprietary platform], what platform do you want the product to run on?"

In imitation of a Qwest ad from that time, I said, "I want it to run on any operating system, on any database, from any provider." I then glanced at him to make sure he wasn't winding up to smack me in the head. "You asked."

What I was trying to get across is that fighting the platform battle with customers is a certain loser. If they are a Unix shop, and you are trying to sell them Linux, or OS400, it's a nearly impossible task. It's better, frankly, to cut your losses and find another prospect for which your product is a good architectural fit.

Why is that so? A new book helps sort it out. "IT Risk," by George Westerman of MIT's Sloan School and Richard Hunter of the Gartner Group, discusses how companies can and should manage risk within their information-technology infrastructures.

And one of Westerman and Hunter's key points is that a company's foundation architecture must be simple and standardized. Such an architecture can be more easily protected from disaster, can adapt more quickly to changes in the business, and can limit data access to authorized parties more easily than a hodgepodge of separate systems, platforms and applications.

Like it or not, when you are trying to sell a nonconforming software product into a company that has built a simple, standardized IT foundation, you are trying to force them to accept a hodgepodge. And they won't do it.

Product managers need to manage the lifecycle of their architectures as well as the lifecycle of their functionality. It can be painful and expensive, but not as expensive as a good product that loses its market due to an outdated architecture.

, , , , , ,

Thursday, November 15, 2007

Mistake Bank #12 - Don't forget about support!

What follows is a sample of a project I've been working on called the Mistake Bank. It combines narrative, learning from mistakes, video and web2.0 in an environment that companies can use to train new employees, create a corporate history, connect workers and mentors, and bring more humanity to the workplace. Email me at inquiry@caddellinsightgroup.com if you would like to know more about the Mistake Bank.



When John Caddell began his first job as a product manager, he inherited a new product that was being sold by a large partner. And once the first sale happened, he learned that having a support strategy is not optional.

, , , , , , , , , , ,

Friday, September 21, 2007

Worst Practices In Product Management

I had a call with Verizon Wireless yesterday afternoon that went something like this:

Me:
"I got a Blackberry recently and I was trying to use it as a wireless modem for my laptop and I'm having trouble."

Tech Support:
"Let's try some things."

...time passes. We try lots of things. Problem persists...

Tech Support:
"I checked and I found out that you need to activate a feature to enable you to use the Blackberry as a modem. The feature costs $15 per month."

Me:
"What? I am already paying for data access, by the megabyte. Modem support costs $15 more?"

Tech Support:
"Yes, I'm sorry. Would you like to speak to Customer Service?"

...on hold for a while...

Customer Service:
"Yes, sir, that feature is $15 per month."

me:
"How come that wasn't clear when I signed up for the Blackberry service? Plus, I'm already paying you $150 a month."

Customer Service:
"I'm sorry, that's the only way we sell it... think of it this way: It's only $0.50 per day."

me:
"But I only need it occasionally. I can't justify paying $15 per month for occasional use."

Customer Service:
"This might solve your problem. You can activate it when you need it, then deactivate it when you're done. You'd only pay for the days you use in that case."

me:
"I have to call once to activate, then again to turn it off? Every time I want to use it? Why don't you have a daily access?"

Customer Service:
"That's the only way you can do it."

me:
"I might try that, but it's unfortunate that you don't have a plan that helps the occasional user, like me. And I don't like having to pay $15 or even $0.50 per day for something that should have been included with the data feature I already bought."

Customer Service:
"I'm sorry. Can I help you with anything else today?"

* * *

So: no resolution. Tech Support and Customer Service were fine, creative, even approaching that state of bending the rules to satisfy a customer. (Installing rigid processes that force this kind of behavior is a worst practice depicted nicely in a recent post by Dave Snowden.)

It's Product Management I have the problem with. First of all, an additional fee for my laptop to use megabytes I'm already paying for is bad. (It's done so that people who pay $60 per month to use the Verizon PCMCIA card in their laptop won't feel that they're getting ripped off--even though they already do.)

Second of all, not having an occasional-use plan and forcing me, the customer, to do work to synthesize this plan (call to activate, call to deactivate, every time I need the service) is also bad.

Finally, I am a $150 per month wireless customer. (VZW's ARPU is around $50.) I'm a Verizon VIP. Yet there's no accomodation built into the product for my kind of customer.

It's just poor packaging all around. And it needs to be fixed. This is one of the reasons mobile phone customers hate their suppliers.

Aaargh.

Monday, September 17, 2007

Tech support: an area where user-generated content is here to stay

There's a lot of hype out there about user-generated content. Most humorous to me are authors who want their readers to help them write their books. Very Tom Sawyer of them.

In one area of technology, however, user-generated content is king. And that's product technical support. Good manuals are hard to come by, but user forums can answer just about any question you have. Here are two examples.

I just got a BlackBerry World Edition phone. The folks I called from any public place noticed lots and lots of background noise from my end of the conversation. BlackBerry and Verizon's web sites (and Verizon's tech support line) disavowed all knowledge of a problem. Yet the CrackBerry forums had more than forty posts related to the item. No solutions out there yet, but numerous ideas and, at minimum, corroboration that this is a real problem.

I also just got a MacBook Pro, and I was having trouble playing mp3 CDs that I burned on the MacBook in my car CD player. Forget the iTunes or Mac documentation (there's very little of that). But it took 30 seconds at Apple forums to find my issue and suggestions for remedying it.

The unsung heroes here are the users who troll these forums and answer questions for newbies like me.

As for the manufacturers of these products, the least they can do (as Apple does) is to sponsor these forums and make it easy for their users to find them.

Product managers also may want to read them (even if they might not like everything they learn), to really know what's going on with their products.

Monday, September 10, 2007

Why do so many projects fail?

If you've worked on more than a handful of projects in your business career, you are familiar with failure. Lots of projects simply don't work right: some are abandoned before they're complete, others don't meet expectations, others finish but are so agonizing that they burn out teams and managers both.

A new book, "Reinventing Project Management," by Aaron J. Shenhar and Dov Dvir, dissects the topic in great detail. It's a refreshing look at project management, not least because they focus less on the discipline of work breakdown structures and task dependencies and more on what different projects try to achieve and how methodologies and management approach must adapt to the needs of the project.

In summary, there are two reasons why projects fail:

1) the wrong objectives are assessed
2) the management style of the project doesn't match the needs

To point (1) the authors point out the tyranny of the "iron triangle"--(meeting requirements, on time, on budget). The dimensions of the iron triangle are immediately assessable--are we late? have we checked off all the requirements?--but they don't reflect key business value that is only measurable over time. Was our new project a success in the marketplace? Have we developed a technology platform that can support our business for the next decade? It's very possible that a late, over-budget project can be a success in the long term. So the iron triangle needs to be put in perspective.

To point (2) the authors measure projects on four dimensions: novelty, technology, complexity and pace. How any project fits on these four dimensions affects how it should be managed. The wrong management style frequently leads to failure. They cite several examples, including:

  1. NASA's moon-landing project, a success despite radical technological breakthroughs required (super high on the technology scale) and constrained timeframe (fast on the pace scale--"before the decade is out"). The managers of that project proceeded deliberately, built lots of prototypes, and carefully worked out the kinks they found. (As a counter-example, the authors point to the shuttle program, which despite similar technical complexity was rushed through on a compressed budget.)
  2. The Denver airport project, which was managed like a straightforward construction project, despite specifying a state-of-the-art baggage handling system which had not been deployed on a similar scale before (super high on the technology scale).
  3. The Segway. A brilliant and novel technological device (rated as breakthrough on the novelty scale), its failing was the closed nature of its development. Because no prototypes were tested in the marketplace, and little if any market research was done, the Segway was launched into a marketplace that simply didn't need it, or didn't need it at the price.
To succeed, say the authors, you must assess a project based on the four dimensions, and create budgets, schedules, objectives, success criteria, etc., specifically for that project. Doing that gives a worthy project a fighting chance to succeed.