A Google search didn’t reveal the existence of any such model. So, I will assume (till proven wrong), I coined this term 🙂
So, what is it?
“Incompleteness Anxiety” is anxiety arising out of an urge to complete a task that doesn’t need to be completed.
The most prominent examples of this can be found in dealing with emails, messages and RSS feeds. There might be other examples as well.
Let me take the example of email to explain this:
- In email, an unread email is an “incomplete” state. Almost all email clients highlight unread emails inviting an action.
- However, most emails don’t need to be read. But if you leave it unread, the next time you return you don’t remember if you already saw it.
- This gives rise to anxiety to mark emails as read or to move them away and reach a “complete” state.
- I realised this after using HEY for a few days. In the Feed and Paper Trail, HEY doesn’t indicate any unread email differently from a read email. There’s just a line indicating “new since you last visited”. If I go back, without acting on any of the “new” emails and return, there’s no special treatment for the “unread” emails that I didn’t open.
- This takes away the anxiety of using email.
Is this a real thing? Does this make sense? Maybe it is just me.
Note: This is different from FOMO. There’s no fear of missing out on most emails. We don’t open an Amazon confirmation email to see what’s in it, but to complete the “task” of marking the mail as read.
Over the last decade, I have been involved in building hundreds of features. Sometimes to add customer value. At other times to improve internal efficiencies. And many other reasons. The challenge has always been simplifying the solution. It is to find the sweet spot between the complexity of the build vs likelihood of risk or reward.
I started off loving the complex solutions. But have wisened up since then. Here’s how I approach this today.
Start with the problem. Think about the ideal solution that solves the problem completely for your customers. This is likely going to be complex and convoluted to build. (Which means you’ll be slower to market and, hence, slower is validating your hypotheses behind solving the problem in the first place.)
Now evaluate the impact of solving the problem. What’s the outcome going to be? For your customer. For you. What’s the likelihood of that outcome?
Now take a step back and question the solution. Does it need to be as complex? How much can you remove and reduce without reducing the benefits so much that the outcome is no longer useful — for your customers and/or for you?
This step is recursive as you keep simplifying. Where you stop is determined by when:
- The outcome is likely to be no longer useful for your customers.
- The outcome is likely to be no longer useful for you.
- You can’t measure (1) or (2) by simplifying any further.
What remains is something that is probably good enough to be of value to both your customers and you. (This is a simplification of explaining simplification.)
Few examples of simplification I have used in the past.
- Use a static CSV or JSON instead of an interface.
- Hardcoding works. (If you can convince your engineering team.)
- Assume defaults — remove choices and inputs.
- Use rules instead of fancy algorithms.
- Discrete selections instead of open-ended inputs (aka chat-bot).
- Human-powered processes instead of tech solutions.
The goal is not to create fancy tech. It is to solve a problem that your customers value. Bring in the tech once the hypotheses are validated and you need to scale.