I’m pretty lucky. For now, this is the view from my office window. You see all those boats? I get to look out at the water, and those boats, all the time (sun, rain, or snow). But those boats… honestly, I see most of those boats probably hundreds of days per year more than their owners do. I’d bet there’s a large number of them that haven’t moved in years.

The old adage goes “The two happiest days in a boat owner’s life are the day he buys it, and the day he sells it.”

All too often, the tools that we acquire in order to solve our problems or “make our lives better” actually add new problems or new burdens to our lives instead. At least that’s what I have found. You buy the best hand mixer you can find, but the gearing breaks after a year and the beaters won’t stay in, so you have to buy a new one. You buy a new task-tracking application, but the act of changing your work process to accommodate it actually results in lower efficiency than simply using lined paper with a daily list of tasks. As a friend says about the whole Getting Things Done (GTD) methodology, “All you have to do is change the way you work, and it will completely change the way you work.”

Perhaps that’s an unfair criticism of GTD, but the point stands for many tools or technologies. If the investment required to take advantage of, and maintain, a given tool exceeds the value returned by it (the efficiency it provides), it’s not really worth acquiring or using.

Technology promises you the world, but then winds up making the best part of using it when you cut yourself taking it out of the hermetically sealed package it was shipped in from China. Marketing will never tell you about the sharp edges, only the parts of the product that work within the narrow scenarios product management understood and defined.

Whether it’s software or hardware, I’ve spent a lot of time over the last year or so working to eliminate tools that fail to make me more productive or reduce day-to-day friction in my work or personal life. Basically looking around, pondering, “how often do I use this tool?”, and discarding it if the answer isn’t “often” or “all the time.” Tangentially, if there’s a tool that I even use at all because it’s the best option, but rarely do so, I’ll keep it around. PaperKarma is a good example of this, because there’s honestly no other tool that does what it does.

However, a lot of software and hardware that I might’ve found indispensable at one point is open for consideration, and I’m tired of being a technology pack-rat. If a tool isn’t something that I really want to (or have to) use all the time, if there’s no reason to keep it around, then why should I keep it? If it’s taking up space on my phone, tablet, or computer, but I never use it, why would I keep it at all?

As technology moves forward at a breakneck pace, with new model smartphones, tablets, and related peripherals for both arriving at incredible speed and with amazing frequency, we all have to make considered choices about when to acquire technology, when to retire it, and when to replace it. Similarly, as software purveyors all move to make you part of their own walled app and content gardens and mimic or pass each other, they also must fight to maintain relevance in the mind of their users every day.

This is why we see Microsoft building applications for iOS and Android, along with Web-based Office applications – to try and address scenarios that Apple and Google already do. It’s why we saw Apple do a reset on the iWork applications, add Web-based versions (to give PC users something to work with). Finally, it’s why we see Google building Hangout plug-ins for Outlook. It’s trying to inject your tools into a workflow where you are a foreign player.

The problem with this is that it is well-intended, but can only be modestly successful at best. As with the comment about GTD, you have to organically become a part of a user’s workflow. You can’t assert yourself into the space with your own workflow and expect to succeed. Great examples of this include Apple’s iWork applications where users on Macs are trying to collaborate with Microsoft Office users on Windows or Mac. Pages won’t seamlessly interact with Word documents – it always wants to save as a Pages document. The end result is that users are constantly frustrated throwing the documents back and forth, and will usually wind up caving and simply using Office.

Tools, whether hardware, or more likely software, that want to succeed over the long run must follow the below “rules of engagement”:

1. Solve an actual problem faced by your potential users
2. Seamlessly inject yourself into the workflow of the user any any collaborators the user must work with to solve that problem
3. Deliver enough value such that users must engage regularly with your application
4. Don’t create more friction than you remove for your users.

For me, I find that games are easily dismissed. They never solve a real problem, and are an idle-time consumer. Entertain the user or be dismissed and discarded. I downloaded a few photo synchronization apps, in the hopes that one could solve my fundamental annoyances with iPhoto. Both claimed to synchronize all of your photos from your iOS devices to their cloud. The problems with this were two-fold.

1. They didn’t reliably synchronize on their own in the background. Both regularly nagged me to open the app so it could sync
2. They synchronized to a cloud service, when I’ve already made a significant investment in iPhoto.

In the end, I stopped using both apps. They didn’t help me with the task I wanted to accomplish, and in fact made it more burdensome for the little value they did provide.

My primary action item out of this post, then, is a call to action for product managers (or anybody designing app[lication]s):

Make your app easy to learn, easy to engage with, friction-free, and valuable. You may think that the scenario you’ve decided to solve is invaluable, but it may actually be nerd porn that most users could care less about. Nerd porn as I define it is features that geeks creating things add to their technology that most normal users never care about (or miss if they’re omitted).

Solving a real-world problem with a general-use application means doing so in a simple, trivial, non-technical manner, and doing it in a way that makes users fall in love with the tool. It makes them want to engage with it as a tool that feels irreplaceable – that they couldn’t live without. When you’re building a tool (app/hardware/software or other), make your tool truly engaging and frictionless, or prepare to watch users acquire it, attempt to use it, and abandon it – and your business potential going with it.