Better Product Managers, and Product Management

The Bay Bridge is closed, shutting down the major commute artery for thousands and thousands of people.  Luckily, there are public transit alternatives – the BART trains that run under the bay and the high-speed ferries.

That doesn’t mean people are using them. Judging by local news radio reports and anecdotes I’ve heard the last few days, many people would rather drive 15-30 miles out of their way to take alternate bridges through heavily-congested traffic.

Not surprising.  It’s always hard to change ingrained user behavior.  But the other (fixable) problem is that the public transit agencies in the Bay Area have an atrocious first user experience.  Signage on BART is confusing – after living here for 10 years and taking it regularly, I still have to double-check which line I should take (walking back and forth to find the ONE map in the station that will tell me).   It’s difficult to find a timetable – if you don’t know how to check schedules online, you’re flying pretty blind.

Most people I know who’ve switched from driving to BART love it – the extra time to read, check e-mail, or nap.  The savings on gas, tolls, and car maintenance is a lot more than the price of tickets.  But the initial hurdle to get there is too much for most people.

(more…)

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.

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…)