A Brief History of Product Management: Starts With a Spark
Product management was originally seated in marketing but has evolved. It's still misunderstood but it's now getting the recognition it deserves with product people...
One of the biggest challenges product managers face is including the entire organization in product planning while avoiding a phenomenon we often call “design by committee.”
Design by committee has little to do with the feedback you receive itself and everything to do with how you manage it. If you treat every piece of feedback equally and every opinion as truth, you may end up with a bloated, Frankenstein-esque product–a loosely stitched together mashup of various opinions and ideas. This is a common outcome of design by committee.
But the opposite is not much better. If you completely dismiss all the feedback you receive, you’ll face a whole other set of challenges. First, dismissing feedback about the product is a great way to develop a product that fails to serve market needs. And as a secondary result, you’ll probably end up with a group of very unhappy people who are unwilling to share their candid feedback later. This is what happens if you build a product in a vacuum.
Neither situation is ideal, yet both are surprisingly common. The secret to avoiding both of these situations is simple: balance. Today we’ll discuss how to balance these inputs and avoid design by committee.
Design by committee generally starts from a good place. People want to make the best possible product, think they have great ideas, and don’t have any problem sharing them.
In a nutshell, design by committee is what happens when multiple parties are involved in the product design process, and all of their input is treated equally. It gets further exacerbated when all final product decisions are made collectively.
By relying on the wisdom of the crowd, instead of empowering a single person to guide and own the final output from the design process, it’s not uncommon to end up with products full of good intentions that fail to completely satisfy the target market.
The problem is not with the feedback itself, but with how the product team chooses to act on it.
While having feedback from multiple sources is incredibly useful for informing product decisions, there are some nuances for managing the feedback properly. On one hand, you and I both know not every opinion or idea is worth pursuing. On the other, people rarely share ideas they don’t think are good, and you don’t want to discourage anyone from sharing feedback and observations.
Design by committee isn’t limited to technology products; there are plenty of examples from other fields where over-collaboration led to failure and disaster. Take the Pontiac Aztek, for example. General Motors wanted to import some Procter & Gamble-style innovation and let focus groups drive the concept development, while also letting many different internal groups chime in.
The intent was to create a product that was truly a crowd-pleaser. And at face value, taking everyone’s thoughts and concerns into consideration seems like a good way to accomplish this. But the resulting product was a commercial failure. Sales of the Pontiac Aztek reached only a fraction of what was predicted and the vehicle never reached profitability.
“By the time it was done, it came out as this horrible, least-common-denominator vehicle where everyone said, ‘How could you put that on the road?'” remarks Don Morris.
Knowing the potential ramifications of design by committee, avoiding it should be a priority for any product team. Here are some ways to steer your product planning clear of it.
Most product managers don’t walk in the door with a rock-solid reputation that results in immediate empowerment to call the shots without question. It takes time and a track record of success and get people comfortable enough to trust you.
As you build your resume of innovating without wild swings and misses, listening to and incorporating feedback in your planning and using data to inform your decisions is important. These things will help stakeholders feel more comfortable loosening the reins. When they know the end product will achieve the initial goals not by chance but because of thoughtful research and careful consideration of every decision, they’ll be less inclined to worry about the details since they know you’ll handle them.
People will always have opinions. And they’re usually not shy about sharing them with others. Since you can’t control human nature, you can instead try to facilitate productive discussions about these opinions.
For example, when the development team or the sales team discusses a potential new product feature, make sure you’re included in the conversation. This gives you the opportunity to assert your position as the expert and central figure while simultaneously defusing any momentum building up in an echo chamber that lacks your presence.
You shouldn’t position it that you’re there to quash all dissent, but rather to inform the discussion with your expertise, your knowledge of the full situation, and your unique role to turn their input into something useful. And, while you’re default response shouldn’t be “no,” it’s important to let people know they’ve been heard while not making any promises.
While YOU might think you’re CEO of the product, there are plenty of people in your organization who don’t share that line of thinking. So, when you’re not viewed as the “decider,” find someone you trust to serve as your proxy.
“Not all feedback is good. Make sure someone with a little bit of power and influence has the ability to veto or filter suggestions that are unimportant, irrelevant, or not needed,” says Millo’s Preston D Lee, “This will save you time and pain.”
It’s virtually impossible to avoid getting input from the masses. And this is something you should actually encourage. But when all you hear is a barrage of complaints, it can be difficult. One way to curtail things is redirecting potential criticism into something productive. It’s really easy for people to point out the things they don’t like; it’s much harder to focus on the good stuff.
By proactively reaching out to the likely naysayers and soliciting their positive feedback, you can give them a chance to be heard without opening the floodgates for negativity. Ask them what they like about the new ideas, what their favorite thing is, what they’re most looking forward to, etc. It might inform some of your future product communication and marketing while avoiding a bomb-throwing complaint-fest.
The best antidote for an opinion is a fact. By making as much of your product planning based on analytics, data, and input from actual customers, you can sideline a lot of feedback beginning with “I think” or “in my opinion.”
Present the data that’s driving your decision making early and often so your assumptions aren’t questioned (because they’re not really assumptions if you’re basing them on more than a hunch).
“The user voice always speaks the loudest,” says product strategy consultant Eric Weiss, “Everyone on your team is giving their opinion of how they think the user thinks or behaves. What the users actually tell you should trump all opinions in your organization.”
And, if you’ve ruled something out because of the data, don’t be afraid to say that, too. Shooting down someone’s idea because you don’t like it might ruffle feathers, but telling someone their individual opinion doesn’t align with what the market is quantifiably telling you removes emotion from the equation.
And, if someone insists that their idea should be considered, you can insist that proper user testing occurs to validate their hypothesis. Asking someone not core to the product development process can take on the burden of proving their point can diminish the urgency they were feeling to get their way.
All feedback may be welcome, but it must be received at the right time. Finding out during QA that the CEO doesn’t like something and wants it redone won’t make anyone happy. So, make sure you’re soliciting input from stakeholders (particularly executives) early and often.
You can also enforce these “feedback windows” with clear deadlines. Mandating that feedback is received by a specific date puts the pressure on them to put in the time to review and respond while taking the pressure off of you to scramble dealing with a change or complaint later in the process. If people have more opinions and ideas, later on, they can be considered for future releases.
“Committee design is not collaborative. It’s a dictatorship of many, and you’ll be reduced to implementer rather than facilitator,” says Ryan Thomas Riddle and Marcin Treder of UXPin, “In order to remain in control, you must kick everyone out of the process at some point.”
While it might be tempting to throw a temper tantrum when you don’t get your way, that’s not where we’re headed with this point. What we’re referring to in this case is channeling a toddler’s curiosity and asking their favorite question as often as possible: Why?
Whenever someone lobs in a new idea or shares their opinion, ask them WHY they think something should be changed/added/removed. This puts the onus on them to create a clear case and rationale for their input and not just their initial reaction or gut feel. No one can blame you for asking why they’re suggesting something and it creates a healthy dialog.
If every product planning cycle follows the same process, the element of surprise is removed. No one will think you’re “trying to pull a fast one” if they know a consistent path is in place for a concept to reach productization.
When there’s uncertainty about how things happen, people are more likely to feel excluded or interject at inappropriate junctures because they’re afraid they won’t have any other opportunity to provide their input.
One reason people are clamoring to chime in during the product planning process is that they believe they are bright, intelligent, and creative and therefore have something worthwhile to offer. This is actually often true. And you want to make sure they feel empowered to share their feedback so you continue to receive their insight. But, rather than saying “yes” to every request someone makes, focus in on where their input is the most valuable.
Cede control to others when they’re the experts. “Great development teams, are given a brief of the key design targets, an outline and then given the freedom to create the best possible product that fulfills this brief,” says Rory Percival on Product Coalition, “They should be empowered to create the desired product outcomes, but in the way they envisage. This allows creativity to flow, unconstrained.”
When everyone believes they’re being referred to in the realms where they’re best suited to call the shots they’ll be less likely to intercede in places where others are clearly more fit to make decisions.
The product design process benefits from the feedback of various stakeholders and colleagues, but only when it is appropriate and relevant. You can do this by framing the scope of their input before they even open their mouths.
For example, instead of setting things up for open-ended brainstorming, narrow the focus by acknowledging areas of expertise and adding some specificity. “Bob, you’re the expert when it comes to what our technology is capable of, so do you have any performance concerns with our current thinking.”
This gives Bob the opportunity to share their thoughts and opinions, but it limits them to their particular area of expertise. You truly do care what Bob has to say about whether this new feature will slow down the site or create data storage issues… you do NOT necessarily care what Bob thinks about the revenue implications or user interface.
This technique allows the specialists to comment on their domain while not opening the floor for an anything goes free-for-all. By giving various people the opportunity to chime in with their thoughts, you can “check the box” that they’ve been consulted.
Bold innovation makes people uncomfortable… by default you’re doing something that hasn’t been done before. It’s natural for people to resist breaking the mold because using that mold is how you got here and achieved initial success.
When you’re designing by committee, you’re unlikely to find consensus for the different, unusual, trailblazing moves because no one wants to make the wrong decision. But without taking those risks, your product will iterate at best or simply stagnate.
“Product should be a dictatorship. Not consensus driven,” says Michael Arrington of TechCrunch fame, “There are casualties. Hurt feelings. Angry users. But all of those things are necessary if you’re going to create something unique. The iPhone is clearly a vision of a single core team, or maybe even one man. It happened to be a good dream, and that device now dominates mobile culture. But it’s extremely unlikely Apple would have ever built it if they conducted lots of focus groups and customer outreach first. No keyboard? Please.”
Of course “courage” also means we can’t plug our headphones into an iPhone anymore, but last time we checked AirPod and Beats sales figures weren’t a problem for Apple. In a design by committee environment, this move would have never occurred because too many people would have cited concerns about angry customers.