Most of us got into this business to solve problems. But once we start building it can be very hard to lose track of those problems (especially if you’re suffering from the Curse of Knowledge). Perhaps you set out to make reports that help folks understand what they’re spending money on. Six months of development later you have a few reports, and they seem to have relevant data…so you’ve succeeded, right?

Not always. Especially with things as complex as reports (which are all about interpretation), it’s often easy to successfully make a thing without actually solving the problem. Sure, your reports might show people what places they’re spending money, but do they tell them what sort of things they’re spending on? Yes, it works, but it’s not going to change anyone’s life. Whoops…you just built a feature that doesn’t solve your initial problem!

Doug Turnure of Microsoft talks about this at about 7:30 in his 2012 UserConf presentation:

If customers tell you during beta that your features aren’t solving their problems, don’t take it personally. They’re just telling you their experience. Yes, it sucks that you spent so much time on this and didn’t solve the problem. But being mad about it won’t help.

Put your personal feelings aside and revamp. Thankfully, these failures often give you the tech backend to quickly put together something that does work. And when the reviews roll in talking about how your revamped feature breathtakingly solves a problem for users, you’ll know it was worth it.

Launch button courtesy of Steven Depolo