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: (most) everyone filed bugs.  It became easier to “just do it” than to find someone to complain to verbally.
• 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.

Did you like this post? Share it on Twitter now. 

Category: Design   Comment: Add A Comment
Trackback URL: http://www.cindyalvarez.com/blog/design/usability-critical-for-processes-not-just-products/trackback/