Ten Things I Hate

Why people start making these lists and how to actually use one without wasting an afternoon

I have been around long enough to see every productivity trend come and go. The ten things i hate framework is one of the simpler ones that actually sticks because it forces specificity instead of vague complaining. You write down ten concrete things you genuinely dislike about a project, a workflow, a relationship with a vendor, whatever. The trick is being specific enough that each item points toward a fixable action.

How to make a ten things i hate list that produces results

Grab a blank document or open a text file. Do not use a fancy app for the first draft. The friction of choosing a tool slows you down and makes the exercise feel performative instead of useful. Start typing the items as they come up, no editing phase while you write. I learned this the hard way during a migration project where I spent forty minutes formatting bullet points instead of identifying the actual blockers in our deployment pipeline. The list stayed blank for three days after that.

What the list actually does for you

Most people treat this like a venting session. That is not what it is for. The purpose is risk identification through negative focus. When you force yourself to name ten specific grievances, you surface problems that would otherwise stay hidden until they cause a failure later. A standard brainstorm will usually produce three or four surface-level concerns and stop there. The list format pushes past that ceiling because stopping at five feels incomplete. I ran into a situation last year where my team was building a dashboard for client reporting. Our initial review session produced nothing but generic complaints about slow load times and poor UX. We changed the approach and made everyone fill out a ten-item hate list for the same product. Twelve people submitted thirty-six unique issues in under twenty minutes. We caught three architectural problems that we would have missed entirely. Two of those issues ended up being database query design flaws that would have broken under real traffic conditions. We fixed them before deployment instead of during a post-launch emergency.

Where the method breaks down

The biggest limitation is that it amplifies negativity bias. People tend to overreport bad experiences and underreport neutral or positive ones. When I applied this technique to a vendor evaluation last year, the list came back looking like the relationship was completely broken. In reality, the vendor had three solid strengths that balanced out six of the ten complaints. I had to cross-reference the list against a separate positive attributes sheet to get a usable picture. The hate list alone gave a distorted view that would have cost us a rejected contract if I had acted on it blindly. Another issue is that beginners usually write complaints without actionable endpoints. "The interface is ugly" is not a valid entry. It cannot be fixed. "The navigation menu takes three clicks to reach the export function when it should take two" is valid. The difference matters because unactionable items clutter the list and waste review time. I spend about five minutes refining raw submissions into action items before moving to the next phase.

What to do after you finish the list

Sort the ten items by impact, not by how loudly someone complained about each one. A quiet frustration with a security gap usually matters more than a loud complaint about color schemes. I use a simple scoring system: high impact gets a three, medium gets a two, low gets a one. Items scoring three are your immediate priorities. The rest get scheduled or dropped entirely. Once you have ranked them, map each high-impact item to a responsible owner and a deadline. If an item has no clear owner, it stays open and blocks progress. I have seen projects stall for weeks because someone wrote down a problem but never assigned anyone to solve it. The list became a graveyard of good intentions instead of a working document.

This technique works best alongside other evaluation methods rather than standing alone. Pair it with a positive assessment or a requirements traceability matrix to keep the perspective balanced. The hate list will always skew negative by design. That is the feature, not the bug. You just need to remember to look at the other side of the equation before making final decisions.

What I use instead when the list format fails

For highly technical audits where the ten things i hate approach produces too much noise, I switch to a structured failure mode and effects analysis. It covers the same ground with more rigor and less emotional content. The FMEA approach takes longer to set up and requires more discipline, but the output is more defensible in engineering reviews. If you are working in a regulated environment, this is the route to take. For fast-moving teams that need quick signal, the hate list still does the job. I do not recommend this method for personnel conflicts or interpersonal disputes. The specificity that makes it work for projects breaks down when applied to people. Writing "Sarah's attitude is annoying" on a project list creates liability issues and damages team cohesion. Keep the framework focused on systems, processes, and deliverables where concrete fixes exist.

The whole exercise usually takes me between thirty and forty-five minutes from start to final prioritization. That includes the refinement step where I convert raw complaints into actionable items. Without the refinement step, you end up with a paragraph of grumbling that gets filed away and forgotten. The refinement is where the actual value lives. Treat it as non-negotiable.