4 Ways to Turn a Good Idea Into a Bad Product or Service

1. Fall in love with your idea.
Creative people generate lots of ideas. We love ideas. They excite and invigorate us. The ones we love the most can easily start to feel like a part of who we are, and they can even express the ways we want to relate to the world and the world to us. But, when it comes to actually relating to the world, our ideas are almost certainly wrong. They aren’t all wrong – they are just some wrong. And, if we are going to turn them into products that people want to use, we can’t afford to start thinking our ideas are right – no matter how much we love them (I feel like there’s a parenting metaphor here). When they leave our brains and enter the world, all of our ideas must evolve and adjust rapidly. This transformation is core to the process of moving creativity into the realm of innovation.
 
2. Stay in the lab too long.
One of the hardest experiences of my professional life was putting an early stage mobile app into the crucifyingly critical hands of teenagers (and I used to do community organizing!). To make matters worse, it was an app trying to connect them to their schools! It was a beat-down – for months. But, it was also the only way we were going to get feedback quickly and broadly enough to iterate on the product and better understand the problem we were trying to solve – the real problem of communication in schools. Our idea was wrong – but there was enough right to build on. It would have been a whole lot easier to say “no, it’s not ready” and keep developing out of fear of what we might hear if we let people actually use it. However, if you accept that you are even somewhat wrong, this continued protection and isolation of the laboratory is actually a sure-fire way to dig yourself and your product deeper and deeper into holes of wrongness, running at features and investing in ideas that get too big to turn around when the user’s truth finally becomes your reality.
 
3. Respond to user feature requests rather than user problems.
Users will make requests of your product based on their experience using it and/or their knowledge and experience of any similar or complementary products. When we pivoted our mobile communication product from education to healthcare, we took the opportunity to reassess the communication problems our software was trying to solve in the new industry. At the heart of communication complaints from both physicians and administrators was email. It was too spammy. Not built for physician workflows. There was no data tracking. It was overrun by people you really wished didn’t have access to your email address. As we started to redesign and retool our product, we also started to get early user feedback. And, whether in focus groups or one-on-one meetings with early users, as we tried to understand their problems, people constantly asked for features that they believed would solve their problems. If we had built our software based on their ideas and feature requests, we would have built email almost exactly - and exactly as they complained about it. We had to dig much deeper to try and solve a problem and not just fulfill feature requests that would add up to a product they already said wasn’t working for them.
 
4. Sacrifice craftsmanship for expediency - or sacrifice expediency for craftsmanship
You need to have both, and there is no easy answer for which one is right at any particular moment in your product development. It is a constant tradeoff, but one that in the long run needs to trend toward craftsmanship. Building something well so that it delivers speed, performance, reliability, and can scale will rarely come back and bite you. Delivering something that appears to do that but then crumbles just when those attributes are most critical for your users will at best breach your user’s trust in your product and at worst send them running toward a competitor who promises the same. A good team constantly battles out these tradeoffs, and it is in these battles that the various voices of sales, product, engineering, design, and whoever else should have the opportunity to communicate their perspectives and priorities. The more one voice or one perspective drives product design the more likely you are to sacrifice expediency and craftsmanship, one for the other.
 

---