The first step of the Design Thinking methodology is emphathising (aka getting to know your customers). For some OSS vendors, they overlook this step assuming that they know what the customers want. Similarly for an internal project, the project team will act as the proxy on behalf of a large group of OSS users without really knowing what that group wants / needs. We all have our biases.
I recently read an article that spoke about an investigation into childhood obesity. The researchers found that they received the best input from the edges of the bell curve (ie the sedentary end and the ultra-active end of the scale) as they were able to articulate their thoughts from the extremes unlike the majority.
What are the ramifications for OSS?
If it’s not viable for you to poll your entire audience, then get to know the extremes:
- Who are the heavy users vs who are the light users?
- Who are pushing the boundaries of your functionality vs who use only a small subset?
- Who is gaining the most exciting insight vs who are just going through the motions?
- Who is connecting to the largest number of device types vs a single type?
- Who is handling the largest change/delta per day versus who is having little change in their network and data?
One example that springs quickly to mind relates to the first dot point. I’ve seen many products that work for individual designs, but their design workflows aren’t efficient at scale and customers have to develop workarounds. The design interface might be support a single design per hour, but the interface doesn’t support bulk loads of hundreds of pre-designs at a time.
The question to resolve is, do you have customers at both ends of any given scale?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email