Better Product Managers, and Product Management

Why Are So Many Products Poorly Designed? (Part 2)

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: 5% [?]

Popularity: 5% [?]
  • Eric

    Finally got around to reading this – great post Cindy.  The reasons you cite are far too common!

  • Anonymous

    Product Managers must spend more time on field rather in Air-Conditioned board rooms, get closure to market / ground reality, user preferences and delivery pain points.

    Building domain expertise is one way of creating good product and continue to be good.

    For product companies, it is imperative that attrition is low and people learn about domain.

    http://successmanagers.blogspot.com/ 
    twitter.com/mathurabhay

  • Johnmurray4040

    It would be helpful if you stated who your target readers are: people in early-stage start-ups, medium-sized companies, and Fortune 500 companies? It would also be helpful if you stated you assume your reader is attempting to sell into. For example,  we know that what needs to be done (and hence advice offered) is fundamentally different between, say, and early stage startup taking a new product into an early adopter market compared to an existing Fortune 500 upgrading an existing product in an existing installed base.

    Thanks for your insights

blog comments powered by Disqus