Thinking tool: Climb the user-contact ladder
When building anything, you will do much better by empathising with your users to understand their problems, and iterating in short cycles on user feedback.
"Anything" really is anything. The most common form is a product for customers, but a blog post is in some sense a product for your readers - and even a games night is a "product" for your friends.
To do this well, get as close to your users as possible:
- Be a user: Make something you yourself want to use, or that solves your own problem. For example:
- Linux was created by Linus Torvalds because he was annoyed by the cost and commercial licensing limits of other operating systems. As part of this he realised he needed a way to track source code, so created git. Most computers now run on Linux, and git is the number one source code tracking tool.
- Slack was initially created for a team of video game developers to chat to each other, after they were frustrated by other chat platforms at the time. Their video game (Glitch) wasn't nearly as successful as the platform they actually built to use for themselves.
- At Palantir, we'd often build tools for operational staff. One of the most useful ways to improve them was to actually use the interface for a couple of hours. You'd discover a bunch of things that'd annoy you, or that could make you more effective. You'd go and fix them, and could iterate like this a few times.
- Most of my open-source software projects, and all of the ones that have gained traction, have been for my own use.
- Talk to users with good questions
- At BlueDot, we'd spend a lot of time speaking with prospective applicants about their background, what led them to the course, and their motivations (which were, in effect, the "problems" they were trying to solve).
- For more on how to ask good questions, see the Mom Test. As some initial pointers: ask about their life, their past behaviour, the problem, and what they've previously done to fix it. Do not ask about your idea.
- Role-play as a user
- This is where you imagine you are a customer with a problem, write down what you'd think, feel and do, then iterate on this through steps of solving your problem.
- This is particularly valuable when you don't have access to users, e.g. they're expensive or time-consuming to reach, or they can't advocate for themselves coherently.
- Think about what users want
- Imagining what users want is much weaker than seeing what they actually do: you often miss the alternatives users have available, or practicalities like "how would a user know the right next step?". However, at least vaguely thinking about what user problems you're solving helps a bit!
- Don't think about users
-
It's sadly common for people to forget about users entirely, especially if they're in "I must finish this deliverable" mode.
If you notice your team is in this mode, even just a little thought can significantly change your plans for the better!
-
Related concepts
This is part of my thinking tools series. Also consider:
- Find problems, not applications for solutions: when speaking with users, focus on finding a key problem, not shopping around a solution
- Empathetic role-playing as a user: probably the best way of thinking about users, if you don't actually have access to them
- Empathy as a general career superpower: in general, empathy is extremely useful for properly understanding user needs
- Shorten cycle times, reduce batch sizes: short cycles let you act on user contact quickly
- Build feedback loops: user contact is the feedback signal for most products