There is a persistent myth about Silicon Valley that great products spring fully formed from the brains of geniuses like Mark Zuckerberg or Steve Jobs. There is a constant search for The Next Big Thing, and venture capitalists spend their days trying to separate out great ideas from terrible ones based on a PowerPoint presentation and whether they happen to think that the founder has what it takes.
The truth is that ideas are free. Even worse, ideas are easy and fun to create, which means that, for any given product, you have far more “great” ideas than you could ever build and test.
Where Ideas Should Come From
Good ideas start with understanding. Specifically, you’ll come up with better ideas if you understand your users, your product, and your team’s capabilities. But they also come from being able to take that understanding and turn it into features that affect user behavior in a predictable way.
Again, I’m not saying that you should go out and ask users what they want and then build it. I’ve never said that. Nobody credible has ever said that. However, when companies are struggling because they are releasing feature after feature that users don’t care about, it’s always because they don’t understand their users’ actual needs. The teams are releasing things they think users should want. Or they’re releasing things that the team thinks are cool, which is a problem when the team isn’t made up of users of the product.
Any of the generative research methods from the previous chapters will help you understand your users—things like observing current or potential users, doing customer interviews, and spending time trying to spot problem patterns. Once you’ve done that research, though, you need to turn it into ideas for solutions. And this is tricky. Let me give you a ridiculous example.
Often, when I’m speaking to large groups of people, I ask who would love to lose 10 pounds overnight. More than a few hands generally go up. Great. I’ve spotted a problem pattern. This problem pattern
is supported by data, by the way, since the diet industry in the U.S. alone is tens of billions of dollars each year.
Next, I present people with my brilliant solution. They can lose 10 pounds overnight by cutting off a leg. I never get any takers.
Great problem identification. Suboptimal solution identification.
Of course, cutting off somebody’s leg will remove ten pounds. But most people want both of their legs. It’s a “solution” to the problem that doesn’t show any understanding of the real user need. If, instead of focusing on the metric of “10 pounds” we focused on what those 10 pounds represent, we’d be able to identify this particular solution as a nonstarter before we went out and invested in bone saws and operating rooms. I know. It’s a silly example.
But the truth is that companies often do release new products and features that nobody wants or uses. Even more frustrating, often multiple companies will create products intended to solve the same problem, but one will succeed where the others fail. Either the successful companies have a better understanding of the users for whom they are building their products, or they’re simply better at coming up with ideas that turn into appealing features.
Why do so many great product people generate such crappy ideas?
Where Ideas (Unfortunately) Come From
Sadly, many product and feature ideas come from everywhere but users. In fact, the incredibly dismissive quote, “Users don’t know what they want,” is frequently used to prove why we shouldn’t be listening to users. That’s unfortunate, because we’re sure listening to everybody else.
Management
“Why exactly are we building this?” “Oh, the CEO wants it.”
Whether you’re at a startup or a large company, you’ve probably run into this problem. Unless you’re at the top of the org chart, there is somebody above you who has ideas about how the product should be built.
At startups, it’s generally founders who have an incredibly strong vision for what you should be building, and they’re not the least bit interested in hearing any argument about it. At large companies, the ideas and product suggestions can be handed down through several layers of management, which means that you don’t even know whom to convince it’s a terrible idea.
It’s maddening, and it creates environments where UX designers, researchers, and product managers feel disempowered. This is so common that it has an acronym: the HiPPO, or highest paid person’s opinion.
The problem is that even people who have had fabulous ideas in the past or who have started very successful companies can have a failure. Remember the Amazon Fire Phone? The rumors are that the entire design and production were heavily influenced by Amazon CEO Jeff Bezos. It also appears to have ended with a $170 million write-down due to unsold inventory and a product that is no longer available for purchase. Jeff Bezos has had a lot of great ideas and built an amazingly successful company. But not every one of his ideas is going to be a winner.
Investors
Even founders don’t get to escape the constant flood of “great ideas” from people above them. Investment from venture capitalists often comes with advice, some of which might be useful, and all of which is hard to ignore.
As with management, the problem is not that investors always have bad ideas. The problem is that those investors are probably not your customers. They’re giving you feedback about a product that they wouldn’t use if they weren’t investing in it. Sometimes, it’s a product that they don’t use anyway. Those ideas are likely to lead you down a path of creating a product that is more appealing to your investors than your customers.
It’s hard to say no to ideas presented to you by a smart person who has given you a lot of money, but sometimes you have to, in order to build the thing that your real customers will love.
Coworkers
Not all ideas that come from within the company come from the top. Your coworkers, teammates, and employees will all have ideas about the product you’re building as well. Some of these ideas will be fantastic, particularly the ones from people who routinely connect with users. For example, your customer service department may have insights into problems that you won’t get from anywhere else.
On the other hand, an awful lot of ideas can be generated by people who have no real input from users and no particular insight into your product. Or worse, ideas can come from coworkers who have an agenda of their own that you may or may not understand.
Competitors
Another very typical way for companies to generate ideas is to take them from their competitors. Even startups will say things like, “Oh, we need to build feature x because that’s the only way to get to feature parity with Startup Y.” And everybody who has ever talked to a corporate marketing department has been told that a feature is needed “as a checkbox” for the market.
As with ideas that come from management, not all of these will be wrong or bad. The problem is that they’re also not particularly likely to be good.
There are two significant problems with taking feature ideas from your competitors. The first is that you have no idea how useful that feature is to your competitor’s users. In other words, that amazing thing that Salesforce just added to their CRM system that probably took them months or even years to build might have been a huge waste of their time. You don’t know why they added it or what their metrics are on it. It’s entirely possible that nobody’s using it, or that it hasn’t improved their bottom line at all. Even successful competitors can make bad product decisions, and blindly following them down that path is likely to lead to failure for you.
The second problem is that your competitor’s users aren’t, by definition, your users. What appeals to the people who use your competitors’ products won’t necessarily solve a problem for your customers. In enterprise software, it’s not uncommon for companies to add features to products for a very specific customer, and if that customer isn’t yours, copying that feature won’t help your business at all.
Design Patterns
Sometimes ideas get stolen from completely different products altogether. This is how we end up with products that bill themselves as Tinder for Dogs or Uber for Ice Cream or Google+.
In other words, sometimes we get ideas from design patterns that have worked in other places. We see how wonderful the design pattern for Pinterest is, and we think how great it would be if our B2B file-sharing app worked the same way.
Adopting useful design patterns from other products is a totally reasonable thing to do, as long as you understand why they’re useful and how to use them appropriately. Simply taking a popular design pattern and applying it randomly to some other product is not a good idea.
Wouldn’t It Be Cool…
The most common place we get ideas seems to be “out of thin air.” These ideas tend to come from brainstorming sessions where people try to come up with “cool” ideas that “people” might like.
These ideas are often generated based on what’s possible or easy to produce rather than on an actual, observable problem. These ideas turn into dashboards with fancy visualizations of data that users don’t really need. Or else they turn into wearable devices that track things that nobody wants tracked. Did you know the Apple Watch lets you send your heartbeat to other Apple Watch users? ‘Nuff said.
Data
OK, this one seems a little weird for me to complain about, since I love data, and I think that metrics help us make much better product decisions. But that’s only true if you use them correctly.
A lot of teams these days are relying entirely on quantitative data to drive decisions. What happens is that a product manager will see a problem with a metric—maybe product pages on an ecommerce site aren’t converting well or churn is high in an enterprise SaaS product. That product manager will then come up with some theories about why the metric is bad and immediately move to ideating about
how to fix the problem. This is generally accompanied by the team building and testing “fixes” for the problem over and over until the problem goes away or, more frequently, the product manager gets told to move on to something else.
The problem with this approach is that the product manager in that case is trying to use metrics for something they don’t do very well— to understand why something is happening. Then the team builds an entire feature or fix around that “understanding.”
What this leads to is a lot more trial and error than is absolutely necessary. Sure, the data can tell you what users are doing with your products, but data can’t tell you why. Until you understand the “why,” you can’t make a good decision about how to fix the problem
What’s a Better Way?
A few years ago, I wrote a book called Build Better Products. This is a lightly edited excerpt from Chapter 5. You learn more and purchase the book at Rosenfeld Media.
