Published May 2016
Every product and project is different, but there are still a few key rules that increase your chance of success. I was lucky enough to be able to share some of these at ICCWS this week.
The premise of my talk was that we should only produce things that people need, not what we think they need. This applies to websites, apps, physical products, promotional strategies. In fact, I can’t think what it doesn’t apply to.
To illustrate this point, I used a few apps as examples. For instance, turning your iPhone into a fan, razor, cigarette lighter doesn’t help anyone.
“They’re just a bit of fun” is the usual excuse I hear for building such products. My response would be “Just a bit of fun took someone time to create, when they could have been doing something useful”. Or maybe they’re preying on the gullible who might pay money for a pointless app? There’s clearly a few people who fall for it!
At least those examples offer new functionality.
The following are trying to make money from existing functionality:
… these are just pointless:
… and this is just downright inappropriate:
So how should we approach building products?
- Find out what people need
- Build a hypothesis (paper prototype or basic functionality?)
- Test the hypothesis
- Repeat process to build something people need (and will pay for)
Many good examples can be found on crowdfunding platforms like Kickstarter: creators don’t build a product then find out if people are willing to buy it; they ask for funding from the masses and only build it if they gain enough interest. I wrote about a wine-based Kickstarter project back in August 2012.
Le Petit Ballon (being discussed next month) and Vivino (discussed in February) are other great examples: they didn’t build a complete product then release it out to the world; they built small bits of functionality which they tested, throwing away what didn’t work and keeping the bits that did.
It’s rare to hit on a killer product in first attempt. Nearly all the best tech products are produced incrementally and iteratively. But this approach works on much more than just technical solutions: build the smallest, testable product … get feedback on that … then refine and improve.