Better Product Managers, and Product Management

As I discussed in the previous post, many products have terrible design because the design team doesn’t get to use the product, and because design is brought into the process too late.

I’m going to discuss two more reasons which extend beyond the design team.

The first one will not be a surprise to anyone who reads this blog regularly — most products are poorly designed because the product leadership failed to get out of the building and talk to customers.  Another way to state it is an overvaluing domain expertise.

Don’t get me wrong – complex products require a product manager who understands the rules of the game. I don’t want to use brokerage software created by someone who doesn’t know a 401K from a 529 plan.

But it takes more than knowing the conventions and constraints to build a great product experience.   You need to be able to anticipate your customers’ concerns and fears, to know where they’re likely to be confused and need reassurance, to understand the context in which they’re using your product.

When you have deep domain knowledge, it’s hard to remember what it was like when you did not have that information.  (see: the “curse of knowledge”, popularly explained in the book Made to Stick).

When I worked with financial software, I commonly heard product managers and engineers explain a certain workflow with “but this is the logical choice!”  How many people do you know who are logical about their money?  Money is emotional.  Things that threaten our money (or anything that is important to us) scare us and turn us into irrational creatures.

Products that are designed by rational humans but used by irrational humans… usually doesn’t result in a positive user experience.

To overcome this, you need to make a conscious and deliberate effort to understand your customers.  What is their mental model? What are they concerned about? What is their comfort level with this task?  You need the ability to put aside your domain expertise and see your product through the eyes of the uninitiated — and this is a challenge.

Most of us work really hard to become experts at something, and it goes against our nature to spend time pretending to not be experts.

The final reason why most products are poorly designed is that the product development process doesn’t get feedback fast enough.

Raise your hand if this sounds familiar:

Company: “Oh, we always do user testing to identify any usability issues or confusion with our products.”

Me: “That sounds good.  When do you usually do your testing?”

Company: “We do our testing when we have a real working beta; that way we’re testing the real app so we get the most accurate results.”

Me: “So, if your testing uncovers major issues, how long do you have to address and fix them?”

Company: “…A few weeks.”

User testing is too often just lip service.  If your product is fundamentally wrong — and if you made the first 3 mistakes I discussed, it almost certainly is — you can’t just patch that up in a couple of weeks. Not only would that require your engineers working 36-hour days, but now your whole organization is invested in the thing that has already been built, is already working, was already promised to customers.

Even if you made incredibly good guesses, even if you talked to customers before you started building — if you wait until the product is 90% complete to get feedback, you might as well have not bothered.  You’ll learn what you should fix in the next version, but for startups, you may not have the luxury of a next version.  This version needs to meet a minimum value threshold or you’re headed for the deadpool.

The way to fix this is simple.

Get feedback sooner.  Build that into your schedule:

• Interview customers before you start building and use that feedback to identify changes to your requirements.
• Show early mockups to customers and iterate based on that feedback.
• Show early prototypes to customers and iterate based on that feedback.
• Find ways to manually emulate the “finished product” experience and share that with customers, iterate based on that feedback.  And, of course
• Look for ways to build the 2-week version and then another 2-week version and then another 2-week version — instead of the 6-week version where you’ve invested a lot of all-or-nothing time.

Sounds like a lot of work.  But the hours you spend on gathering that feedback pale in comparison to the hours you waste when giant features or releases have to be thrown away and redone.  (And let’s not even talk about the morale hit…)

Popularity: 16% [?]

(Originally answered on Quora.)

Why do so many products have crummy design?

Many designers do not (fully) use the product they are designing. Sometimes this is due to laziness on the designer’s part; much more frequently company culture and the product management/engineering organizations are to blame. Why?

Many applications — especially B2B applications — are difficult, if not impossible, to use in an isolated manner.

A single designer who sets up a project in a project management application may be able to input tasks, but they are not truly “using” the product and experiencing the use cases they are designing for unless it has real projects and real team members interacting with it.

For any product that relies on customer data (and nowadays, that’s almost everything: personal financial applications, social, local, analytics, healthcare), you can’t really recognize what is difficult or unclear unless you are looking at your, relevant, personal data. Sample data is a poor substitute (though better than nothing!)

The other reason is that, in many organizations, designers are brought into the process too late.

Instead of being included in early discussions where business goals and constraints are identified, designers are often thrown a fully-written spec and told to “make this pretty”.

This is basically impossible: all the visual design in the world can’t save features and workflows that shouldn’t have been spec’d in the first place.

So how do we fix this?

Here are some of the things that are needed:

• Product management needs to involve design early in the process
• Product management needs to explicitly define problems, business goals, and constraints
• Design needs to also have access to other teams who are familiar with customer problems — customer support*, sales, engineering — and the company culture needs to support a “there are no stupid questions” mindset
• Executive management needs to buy-in to the idea that designers aren’t just there for ‘making it pretty’ (i.e. schedules need to support designers taking part in early meetings)
• Executive management needs to lead, top-down, a company cultural expectation that “everyone uses the product, no exceptions.”
• Design, product management, and engineering need to collaborate to provide internal tools that support use of the product (e.g. sample data, test accounts, training)

*Customer support, incidentally, is the overlooked knowledge gold mine in most companies.  They know why customers are unhappy, cancelling, or singing your praises, but they rarely get to share that info with other teams.

Those are the first 2 reasons – and, in my experience, the most pernicious. Next week I’ll cover the other 2 problems, and how your organization can improve upon them.

Popularity: 19% [?]

Are you designing/coding something with radio buttons or a drop-down menu?  Stop!

I’m going to show you how taking an extra 30 seconds to identify the type of choice and presenting the appropriate defaults can save you a ton of errors, dropoffs, and customer frustrations.

Which of these describe your choice:

There is only one right answer, and that answer is obvious to the customer

Don’t set a default. For radio buttons or checkboxes, that means nothing should be selected.  For dropdown menus, that means adding an explicit first option called “Choose one:” so that the menu doesn’t default to the first alphabetical choice.

There is only one right answer, and that answer is NOT obvious to the customer

Don’t provide options at all. This seems counterintuitive, right?  If you’re asking a hard question, it seems like you should help the customer by telling them what the possible options are.

But what happens is that customers will simply choose an option at random, and if they guessed wrong, an error will happen.  (Very bad if you are doing an emergency funds transfer to save yourself from overdraft!) It’s better to force them to type in an answer, which they will do slowly and with more care.

There are multiple acceptable answers, but you can guess which one would be preferable to the customer

Set a default and (preferably) explain why. I often hear product managers say something like “well, the customer should pick X, but I want to let it be their decision…”  Guess what?  People hate making decisions!   If you know we should pick X, throw us a bone and pre-select X for us.   Please.  We will appreciate having that 5 seconds of my life and those 5 brain cells spared!

There is one answer that is probably right unless [some situation applies]

Set a default and explain clearly what that exception situation is. Offer an email address or more info icon so the customer can feel really sure that the situation does / does not affect them.

Popularity: 13% [?]

I hate the phrase “style guide”.

Having worked with a lot of Fortune 500 companies with massive in-house design teams, it calls up images of enormous, image-dense PDFs specifying “6 pixels of space here” and “use 18pt Verdana bold #999 except when centered, and then use 17pt Georgia bold #D41091 but only with 4 pixels of padding” — hundreds of rules that either no one follows, or people spend hours and hours following precisely (to the detriment of actually releasing any useful features).

So today I’m going to talk about a checklist — one that you probably do not have, but should.

You need an interaction design checklist.

Why do I need this?

Because it’s difficult and expensive to fix interaction design mistakes.  Once a workflow has been designed poorly, it often involves both visual design and touching multiple functional pieces of code to get it right again.

But we already know about good design and usability.

Saying “we’re going to design a usable product” is like saying “I’m going to exercise more”.  It’s a vague New Year’s resolution that will be forgotten by February.  Unless you have specific guidelines that are written down and integrated into your process, you will make mistakes.

Our designer feels like they can’t do good work if there are a bunch of rules.

If your designer can’t work within practical constraints, they’re not much of a designer.  An interaction design checklist is like a set of rules for building a house — you need foundation beams, electrical outlets, windows need to be a certain distance from the ground.  That still leaves a ton of room for innovating on room layouts, materials, and paint colors.

But we do usability testing.

Good!  Keep it up.  But you can’t rely on a handful of user testing subjects to find all of your interaction design mistakes.  For one thing, you probably aren’t testing errors and edge cases.   Also, if you start out with a very flawed design, it’s going to be really expensive and time-consuming to keep iterating and testing.  You’re better off starting with a better first draft.

What should my interaction design checklist include?

Every application will vary, but I’ve put together an Interaction Design Checklist Template for you to download.

It includes:

• First User Experience
• Error Messages
• Confirmations
• Forms
• Optional / Advanced View
• “Money-related stuff”
• No Data / Lots of Data
• Actions and Navigation
• What’s Next
• Other Areas to Consider

Don’t think of this as a big project – use the template as a starting point, and as you develop new features, take a little bit of time to ask some of the questions and create new rules as they make sense for you.   Your checklist should develop over time, as you continue learning about your application and your customers.

Popularity: 13% [?]