If you’re building something to solve a problem, chances are someone is also out there trying to solve it too. Most startups don’t have the luxury of being original, and those that do will find they’re not original for long.
In any market with several competing products, the winner is rarely decided because of any single “killer” feature. Instead, it often comes down to the small details. Small details are often decided in the moment by a single engineer, and will slip into users’ hands without anyone giving it a second thought.
The difference between a product that gets the small details right, versus one that doesn’t, is very difficult to measure. It’s when your users love your product, yet can’t quite describe why. They might say it feels nice to use, or it’s intuitive. You can make a fairly accurate guess whether your product is getting the small details right.
You could spend a lot of time sweating these small details, but that’s basically micromanagement. The team doesn’t have time to talk at length about list item animations. If you are doing this, you’re likely missing the bigger picture.
Instead, push these decisions into the team, and give them the tools they need to make these decisions. The only way to do this is to sit all of them, engineers included, in front of your users.
If you do this, over time, you’ll begin to notice some things:
Small problems with your product will appear, and then disappear
Every time I’ve encouraged an engineer to take part in user research, they’ve returned with some great stories about how everything went wrong.
The thing they’d spent weeks building completely fell apart in the user’s hands. The user didn’t understand the error messages. That obvious button placement was actually not-so-obvious.
The best thing about this is that engineers are natural problem solvers. Your engineers start with horror stories, and start following up with “… so I fixed it.” Your team will start fixing small blemishes as part of the daily flow.
The team will become much more user-focused
As the team gets more comfortable with user feedback, they’ll start to refer to it freely as part of conversation. What was previously rampant speculation about features or design will become a discussion about what Louise saw a user do last week.
If the team often struggles balancing technical tasks with user stories, these will get a lot easier. Those features that the team avoided building because they were too difficult to build? The team will pull them forward.
Why? Because the team now feels their users’ pain. No amount of convincing from a researcher will ever be as convincing as being sat with a user.
Be prepared for the team to start challenging product decisions. As teams gain insight into who uses their product and why, they will challenge decisions which don’t line up with research.
If your product was thought up by an executive in a boardroom, or it has a weak reception from users, prepare for the team to lose faith.
The team will feel more empowered
Everyone I know who speaks to users always comes back with a renewed passion for their work, and a burning need to solve users’ problems. For teams who’ve not yet launched, or have a long time between releases, this can be exactly what they need.
Your product will improve
As the entire team is exposed to your users, they’ll develop empathy, and will develop a common language with which make product decisions. Not only will this give the team the tools to make small decisions, but it will make all the big decisions easier too.
As time goes on, what was a thousand small compromises will become a thousand small delights. For your users, this could be the difference between someone thinking it’s okay, and loving it. The more people who love your product, the more likely you are to succeed.