Patton's Advice for Product Managers
“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”
– General George S. Patton, Jr.
Patton was quite a character. From what I know of him, it sounds like he would have been quite a product manager. He’s the source of countless quotes and advice, but I wanted to talk about the quote above and how I think it applies to product managers in two very important senses.
First, on the receiving end, customers and users will very often try to tell you as product manager *how* your product should work, rather than *what* your product should do. We all have experienced this, as it’s very much human nature to try to envision solutions to problems. But when a product manager focuses on *what* the product should do it’s pretty amazing how many possibilities open up as to how to best solve the problem.
I’ve written elsewhere about the underlying reasons why customers and users really aren’t in a position to come up with a good solution themselves. But the bottom line is that there’s a big difference between customer requirements and product requirements.
What I haven’t yet talked about is the other side of this point, where the product manager tells the UI designers and engineers *how* to design and build the product, rather than telling them *what* the product needs to do. This is an especially common problem with UI design (aka product design, interaction design, or information architecture). This problem is exacerbated by the fact that companies typically have too few design resources, and sometimes the product manager is in fact the only person available to do the interaction design.
Unfortunately, the skills for interaction design are very different from product management, and it’s the rare product manager that’s good at both. Another problem I see that complicates this is that in many companies, the UI design resources are part of a service organization where they’re pulled in “as needed” to help with design after the PRD is complete. The problem here is that this severely limits the contribution of a good designer. They are most valuable very early in the process, when the product manager is working to understand the target market and come up with a solution.
A product manager that a) has a good appreciation for the role of product design; b) in a company that has the product design function staffed and available; and c) where the product manager gives the product designer the latitude to come up with solutions that meet the needs, has a big advantage in coming up with winning products.
Strong product/UI designers are hard to find. In my opinion, there are too few good academic programs turning out too few of these critically important people. But when you do find one, be sure to fully utilize her. Make the designer a key part of your product team, and include her in your customer visits, user profiling, product brainstorming, and in deciding your product strategy and roadmap. Let her explore alternative designs and listen closely to her input in terms of user behavior and preferences.
All of the above applies with engineers as well. The engineering team doesn’t appreciate the product manager spelling out the details of the implementation any more than the product manager wants the customer to dictate the specifics of the requirements. In my experience, this is somewhat less frequent because the line between product managers and engineers is fairly clear, but when I review PRD’s I find that it still happens a great deal.
Note that if you want to learn more about product/UI design, a site and newsletter that I like a lot is www.goodexperience.com written by Mark Hurst. Also, one of my favorite books on this topic is “The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How To Restore the Sanity” by Alan Cooper.