How to avoid building products that fail
It’s all about needs.
“If I had asked people what they wanted, they would have said faster horses.” Far too often, we hear those words (supposedly spoken by Henry Ford) as a way to justify rushing headlong into executing a so-called innovation before the idea is tested with users. It’s worth noting that not only did Henry Ford probably never speak those words, it also turns out that kind of thinking resulted in “a catastrophic loss of market share from which [Ford] never recovered.”
The lesson we should take from this story is that it’s extremely dangerous to execute ideas without first identifying and testing assumptions about the value of those ideas. We shouldn’t jump to a solution before we understand the problem. And that’s what this post is about.
When it comes to building products, the starting point is — always—needs. Not what we assume would be cool, but what users or the business need to be successful. Different inputs into this process include the following, which we’ll discuss in detail in this post:
- User needs. We must have a good understanding of the market, the company’s customers (existing and potential), and their behaviors and attitudes. We should never be caught off guard by questions about the product’s target audience.
- Business needs. The “putting users first” mantra too often neglects the fact that a product exists to make money. Having revenue goals is not an excuse for bad design, though.
- Technical needs. Development needs get ignored much of the time in favor of the more tangible front-end and business requirements. Developers know the limitations of the product; they know what needs to be fixed, and they know what technical debt needs to be paid.
One of the biggest mistakes we can make in product development is jumping to execution before an appropriate planning cycle has been completed, so we need to give planning the attention it deserves. Let’s start…
