Solutions Don't Have To Work For Everyone
I used to believe that when I added a new feature to a web application, said feature had to help all users. But, as I've grown older - and I've had to operate under greater constraints at work - I've come to embrace the idea that solutions don't have to work for everyone. A solution that adds value to some segment of users is just that: a value-add. And, there's nothing wrong with incrementally adding value to an application. Especially if you're incrementally adding value on a regular basis. In retrospect this is so obvious that it seems silly to have to articulate; but, this was not always obvious to me. And, I'm excited to be adding more measure and perspective to my current Product Thinking.
Over the weekend, I read Shape Up by Ryan Singer. In this new book from Basecamp, Singer wrote a passage that I interpret as speaking directly to this outlook:
It helps to shift the point of comparison. Instead of comparing up against the ideal, compare down to baseline - the current reality for customers. How do customers solve this problem today, without this feature? What's the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn't work or wait for a solution because we aren't sure if design A might be better than design B?
Seeing that our work so far is better than the current alternatives makes us feel better about the progress we've made. This motivates us to make calls on the things that are slowing us down. It's less about us and more about value for the customer. It's the difference between "never good enough" and "better than what they have now." We can say "Okay, this isn't perfect, but it definitely works and customers will feel like this is a big improvement for them." (Page 105)
In particular, this line hits me right in the gut:
"It's less about us and more about value for the customer."
When I reflect on the past, and look - with honesty - at the times that I decided not to build something, it was often about me, not the user. It was insecurity about whether or not I had the skills needed to build something; it was pride in being able to poke holes in an idea; it was spite; it was jealously; it was close-mindedness. It was a lot of things that embody the frailness of the human condition.
But, I'm excited now! My self-deceptions have been lifted and I can see more clearly that creating a better product - and a better user experience - doesn't have to be a series of disruption events. It can be a steady stream of minor improvements; of small solutions that help some set of users. And, if I can do that, consistently, day after day, I have confidence that it will lead somewhere great.