That is what my colleague Jeff Huleatt said to me the other day after explaining my idea for a new feature that I wanted to add to our blog. We can get really invested into the product we are working on and miss everything else around us.
Product blinders
I call this product blinders. We get narrowly focused on a product and totally miss a very obvious thing that an outsider would have spotted. Long exposure to a product or device blinds us to its flaws. After years of working in tech, I realize how often I get blinded to a product’s flaws. I get so deep into the product story that I sometimes forget what could improve the feature that I am currently working on. I worry about the next feature in the product to make a more cohesive story or to advance the overall product narrative.
Examples of me having product blinders
Here are a few examples of cases where I have been blind to my product because I was so focused on the product and not the larger story.
API design
Sometimes this comes out in the APIs that we design. They aren’t always straightforward and need someone to come in and point out our rough edges or things that don’t always make sense. For instance, when I worked on the web version of the Android Package Signer utility, I originally had six different method calls that a user of the library needed to call before they could get to the signing portion of the utility. After discussing with my manager, we got it down to two method calls. It took someone else looking at my code to help me see the developer friendly path. Developers want one method call, not six, to work with the product.
Seeing nails everywhere
When you have a hammer, everything looks like a nail. That is certainly true when you start getting really invested into a framework or a product. I recently was thinking of ways to integrate more AI into my workflows at work and had been excitedly getting a lot of personal use out of the ADK. I built a proof of concept tool that reads diffs in PRs to a GitHub repo and figures out if a date existed in the diff. If so, it would schedule a task using Google cloud tasks and then execute a certain function. I explained this to my colleague Jeff who mentioned that this was a cron job. I had totally blanked in my excitement and had invented a more expensive way to do the same exact thing. Jeff validated the idea was good (Jeff is really too kind to me), but was able to pinpoint that this had already been invented. I had totally blinded myself to an existing solution.
Not all product blinders are necessarily bad
Time is a limited resource and how we spend that time can sometimes determine how advanced our product eventually becomes. Not having a well defined onboarding story can sometimes mean that a more advanced story emerges. We see this in loads of projects. For instance, look at VIM. It is very hostile to new users. Out of the box you get a text editor that is incredibly fast that allows you to edit at the speed of light and switch between files incredibly well. But for most new users, once they launch VIM, if they ever figure out how to edit a file, the only way they know how to exit VIM is to unplug their computer. If the maintainers of VIM spent more time on making the new user experience more friendly with menus, a UI built in Electron, and automatic language server integration, the user experience would have improved but the raw power that VIM contains may not have been unlocked. Having product blinders allows for complex solutions to emerge for complex problems without diluting the solution for everyone.
Where product blinders come up in DevRel
Fortunately, for the last year or so, I got to try out a bunch of different products and give feedback directly to the teams. In almost every instance of trying out a product, I found a rough edge. An API had changed between docs and production, reasonable defaults weren’t used, some method calls seemed extraneous, etc… I usually found these issues in products I don’t normally support or are not directly involved in. It comes back to having a fresh pair of eyes examine a problem and notice all the rough edges because they weren’t involved directly in the product making. In my own products that I do support, my team brings fresh usability issues to me all the time with regards to the product. Even customers bring up the usability issues through YouTube comments and other messaging channels. We do our best to catch these prior to getting released but aren’t always that fortunate. Part of being in DevRel sometimes means forgetting how the product you support works and trying to figure out where the rough edges are so you can smooth the product down to something that developers are immediately drawn to use.
