How to avoid analysis paralysis and get real in digital product development.
1. Get out of the lab
Like Macy Gray would say, you need to get up and get out… how will you make it if you never even try? Product people—as opposed to marketing people—love to work endlessly pushing the last pixel and picking the perfect hue for their user interfaces. We want elements to align perfectly, flow seamlessly and behave just right before we make them live. One thing we fail to realize—or worse, we realize but choose to ignore—is that we might be polishing up a user interface for a feature nobody cares about. I am not suggesting you release stuff that is half-baked, but do release something good enough to allow you to get reactions from real users. If they find enough value in a feature that is not fully polished, they will continue to use your product until it works well (think how we continue to happily pay for Netflix even if sometimes it pauses to buffer and even if the rewind feature sucks). On the other hand, the slickest user interface will not save a product or feature for which customers don’t see value beyond the aesthetics.
2. Fail small (so no one notices)
Failing early and small allows you to obtain very valuable information without risking wide exposure or embarrassment. Version 1.0 of anything will never be perfect and you need to treat it almost as a market exploration exercise. Use the early versions of a product to get a read of what your customers care about. Measure everything that matters to your business model. Tweak small pieces, release them and see how the metrics change. Do these small tweaks move the metrics in the right direction? If so, double down. If not, roll back. Fail small. Don’t do a ribbon cutting ceremony and don’t send a press release. Do a soft launch instead and iterate until it’s perfect. Failing small will keep you on track and moving in the right direction.
3. Throw away your to-do list
It is the bug tracker with hundreds of open tickets. It is the post-it note sitting on your desktop with tasks you added more than six months ago. It is the fridge magnet thingy nagging at you every time you see it. If you haven’t done what’s on your list for some time, throw it away. Much in the same way you should donate clothes you didn’t wear for a year, if you haven’t gotten things done in a while, those things most likely don’t matter much. I’ll never forget the advice a brilliant developer, successful CTO (and a great guy to boot) gave me when I asked him how he managed to migrate the opened tickets from one bug tracker to another; he said “start over”. The tickets that are important and relevant, will be re-added sooner or later.
4. Don’t solve problems you don’t have
So your product is almost ready for release and the team is performing final QA. You’re very excited about launching and you want everything to go perfectly smooth. So you ask your developers to run stress and load testing. The test results are discouraging; the product can serve only a handful of users at any given time before it becomes painfully slow. So you decide to delay the launch for a week and embark on developing extra capacity to handle 10 times the number of concurrent users. Developers get to work on caching and sweepers, and it is not one, but two weeks since you postponed the launch, and the product still isn’t ready. Then someone discovers that this one inefficient database query is slowing everything down for everyone else. So everyone turns to measuring and coming up with ways to make the queries more efficient. You should have launched four weeks ago and you didn’t because you couldn’t accommodate the traffic you assumed you’d have. You solved a problem you never had, while you could have done points #1 and #2 above to maybe realize that most of the queries you fixed, were for features that would be nixed in the next iteration because nobody cared about them.
5. Let the Creative Department fix it
Software developers are problem solvers. They get a kick out of making something work or making it work better. I hold a profound admiration for their ability to build stuff out of thin air and for being able to stop the bleeding on a system that’s gone out of control. But as much as I admire developers, I came to realize that most of them are not the greatest product managers. It is because they love what they do so much, that they often have a hard time knowing when to stop and to look for alternative, more economical and most importantly, less disruptive ways to fix a problem. Here’s an example. Years ago, I was part of a team that managed two independent systems, one was a blogging platform and the other, an email system. The two systems were used by the same group of users and the development team thought it would be great if we could implement single sign on across both platforms (web-based single sign on was a fairly new concept and OpenId was just starting to be popular at the time). When we explained the feature and the level of effort to our CEO, he said forget it. Force them to log in twice; it is a security feature! Having to log in again when going from your blog to your email means that the system is more secure. After all, you wouldn’t want single sign on for all the bank and credit cards in your wallet!