In the tech industry we’re reasonably good at capturing needs. Sometimes we skip the needs (or assume them) and go straight to requirements. That’s not great, but the intention is roughly the same: an expression of what (we believe) people need. We even have people for whom this is a significant part of their job. They include user researchers and business analysts. And we write down those needs, track them, and aim to fulfill them. They are “positive” needs.

But sometimes we also discover (and need to capture) what people don’t need. These are things that in another context might be considered features, but to our target users only make their life more difficult. These might include things like “I don’t want to delegate my budget submission; that would be a nightmare,” or “Don’t let me juggle that across two PCs, it would only confuse things.” In reality, like user needs, they may not be expressed as clearly as that, and might well be derived from careful observation and questioning.

I first heard the phrase “anti-needs” for things like this from my colleague Simon Houghton in early 2017. If there is an earlier reference I’d welcome it.

I don’t know the best way to capture anti-needs, because achieving them successful involves not doing something. But it’s definitely in the realm of having the vision for our overall delivery (product management) and comes from work directly with users (the user researcher). It’s all part of “Doing the hard work to make it simple”.

Photo by e OrimO

7 thoughts on “Anti-needs

  1. Surely “Enemies” would be better to describe stakeholders that don’t want your project to succeed? “Victims” are those stakeholders that may be negatively impacted by actions of other stakeholders (Enemies, as well as unintentioned side-effects of other stakeholder needs), and who also may be powerless and require Advocates (another type of stakeholder) to represent them. Sorry .. a bit off topic of original post.

  2. I like the idea of ‘anti-needs’. A stakeholder may have difficultly communicating what they want (maybe because they are also trying to think of a solution at the same time), but have no trouble in telling you what they DON’T want. A useful elicitation technique.

    ‘Anti-needs’ can be formalised as estimated impact ‘side effects’, and quantified in a Impact Estimation Table.

  3. Ah, if the current trend of collaborative development and delighting your users goes awry, we can always create an alternative approach that talks about Victims and Enemies. I can see “releases” become “impositions” and “acceptance criteria” become “tolerance criteria”… ;-)

  4. Aha. You want this?
    Stakeholder: No, not that.
    Good technique for better understanding. Better first ask, rather than finding out you developed a great solution for the wrong problem.

  5. Enemies, may have a reason to oppose. Perhaps they simply don’t like you.
    Victims are those who are adversely affected by the results of what you are planning to do.
    Typical examples I use: Narita Airport opening delay, Chinese development ( slide 79/80). If you Google Narita airport, you can see that still now, planes have to roll around some farms, of which the farmers by now are probably >120 years old.

Comments are closed.