Workaround driven product development

2015-09-13 2 min read

    As engineers, it’s easy to get focused on technical problems and lose sight of the business. We realize our code will be used externally but we have a tendency to focus on what’s close to home rather than the actual real world usage. One of the biggest eye openers for me has been seeing people interact with our products.

    We like to think of ourselves as “hackers” but it’s amazing to see the length people go to “hack” our products to do what they want. Whether it’s someone keeping multiple tabs open to be able to reference information back and forth and avoid losing data or someone registering multiple accounts to bypass a database uniquness constraint - it’s a way for people to bypass the intended design and I’d argue that these “hackers” are a sign of a useful product. In fact, I’d argue that if people aren’t hacking around a product’s limitations it’s not a good one. These workarounds are a sign that the product is so useful that people are willing to go through additional manual effort to use it for a different use case. If that’s not a sign of new functionality to support I don’t know what is.

    And the best way to understand these workarounds is to talk to our customers and collect as much information as we can. Guessing people’s intentions isn’t helpful but being able to identify an anomalyous flow and then talking to that person is a great way to understand the intention and the workaround. This insight can then help drive product direction and innovation.