Better Product Managers, and Product Management

Show of hands: how many of you work for a company who does user testing on their internal processes?  You know – time tracking, IT security, bug filing, feature change requests…

Unless you work for a company firmly grounded in lean manufacturing practices, I’m guessing none.   A process is defined; now it’s your job to follow it. Except:

He was talking about the difficulty of getting employees at his company to actually follow his security policies: encrypting data on memory sticks, not sharing passwords, not logging in from untrusted wireless networks. “We have to make people understand the risks,” he said.

It seems to me that his co-workers understand the risks better than he does. They know what the real risks are at work, and that they all revolve around not getting the job done.  - Schneier on Security: Risk Intuition

Schneier writes about IT security, so his approach is to use a bigger stick.  If you increase the severity of punishment for security violations, then your employees will consider that a bigger risk than circumventing them to save a few minutes. I say to him, “good luck with that.”

If something is difficult to do, people will not do it. It doesn’t matter that they may be fired.

If you want compliance with processes, make them as easy and fast as possible to perform.

Product managers, you may not create your internal processes, but you can still push for change.  Next time you find yourself putting off a burdensome but necessary task, take a few minutes to think about how it could be streamlined.   Make a suggestion, mock something up, document the opportunity cost.

At a previous company, we used a bug database package with terrible UI.  Who cares, right? It’s an internal tool only.  Except that the terrible UI meant that you frequently typed in a long bug description only to hit the wrong button and lose all your data.  Even if you followed the workflow correctly, it took at least 5 minutes to log in, set up the right screen, un-select the irrelevant options, enter your data, and submit.

• Result: no one but QA and customer service ever filed bugs.  There were dozens of bugs that sales and engineers and account management and execs knew about, but never got around to filing.
• Result: Product Management prioritized bugs based on incomplete knowledge.
• Result: patch releases didn’t include those high-priority bugs, and account managers had to look foolish as repeated patches were released that still didn’t address that minor – but highly noticeable – bug.

Then we switched tools to a simple, web-based, single screen system.  Invested about 2 person-days in customizing the template with intelligent defaults, big textarea boxes for typing, fewer required fields.  Time to file a bug dropped from 5 minutes+ to 30 seconds.  There was no excuse to not file a bug – it took longer to complain about a bug than to just file the damn thing yourself.

• Result: everyone filed bugs.
• Result: Product Management had a really clear picture of the issues with their products and could prioritize effectively
• Result: the biggest and most noticeable issues were fixed promptly, and at least for issues that weren’t fixed, we knew about them.  Huge reduction in embarrassing surprised in front of customers.

Keeping your processes usable really boils down to one practice: whenever you find yourself doing something tedious, think about what’s making it long/difficult/frustrating and how you can reduce that.

Popularity: 1% [?]

There’s a new post over at On Product Management about blenders, and what they tell us about simplicity.

Now, as it happens, my blender of choice is not a simple blender.

I’m a dedicated – but very non-fussy/pragmatic – gourmet cook, and I love my BlendTec.  (You may recognize the name from the “Will It Blend?” YouTube videos, which are brilliant.).

Simplicity is one way to think about it. Designing the whole product experience is another.

Saeed writes:

The usage scenario goes something like this:

1. Place the contents to be blended into the blending  container
2. Blend for 10-15 seconds (maybe 20 seconds in extreme cases)
3. Pour the contents out of the container

That certainly sounds like the types of usage scenarios I typically read in Product Requirements docs.  But it illustrates the difference between “designing the product” and “designing the whole product experience.”

(more…)

Popularity: 4% [?]

Here’s why I won’t be using Hunch:

Anatomy of a bad user experience – step by step:

1. Read an article about Hunch, remembered that I had a beta account.
2. Thought of a question that I wanted an answer to.
3. Went to hunch.com and tried to type it in – you CANNOT ask a new question.  If what you typed doesn’t match a pre-existing topic, there is no call to action to create one.
4. Logged in – maybe only logged-in people can create a topic?
5. Clicked on “Create new topic”
6. Got the above image – basically “no, you can’t do what you want until you jump through these hoops.”

I understand that the system needs to be “seeded” with information.  This is not the way to do it.

Any product where the first user experience actually uses the words “Come back when you’re done” needs an immediate rethinking.

Popularity: 1% [?]

My husband just unwrapped his brand-new IBM ThinkPad.  As he was turning it over, marveling at how light it is, he noticed one small feature: a hole.

The underside of the keyboard has a hole in it, so that if you spill liquid on the keyboard — and lots of us have done it, we know it happens — it will drain out easily.

Adding a hole was not a feat of technical engineering.  It didn’t require special materials or sophisticated machinery.  It was just a case of someone thinking about what it’s like to knock over your glass of water and curse and turn your laptop upside down banging on the bottom and hoping that the water will leak back out and wondering if a hairdryer will make things worse – and saying, “We know this will happen.  How can we minimize the damage when it does?”

This isn’t the kind of feature that’s going to win you points up front.  But someone is going to be saved by it, and that person is going to be a ThinkPad evangelist for life (or at least the next couple of years, which is pretty equivalent to “life” in the high-tech world).

Popularity: 1% [?]