Apart from my regular job, I love to work on small projects on weekends. Mainly to learn a new technology or scratch my own itch or both!
The problem with solving for yourself is that you are almost always biased on what new features gets priority in the product and how they should be implemented. There is a lack of diverse thought that brings in a holistic perspective to problem-solving.
It doesn’t have to be like this though. Even an Indie hacker can use various techniques towards problem solving and thus product development.
Lets get some context
I have to work with a lot of JSON data in my current work project. Specially unformatted JSON strings in logs and mock JSON strings in unit tests.
Working with unformatted data from multiple logs trying to do a root cause analysis was a pain when I tried to use any of the top JSON formatter web apps.
Thus, jsontoolbox was born. Aim of JTB was to enable me to work with data from multiple logs at the same time and a few other features made specifically for my use case.
As soon as I created this, I shared it with my friends and colleagues to get some feedback. As expected, it was well appreciated(I’ve got nice and polite friends) and I started to get diverse feature asks. They basically wanted me to add features from all other similar tools.
It was good to get feedback, but it was not practical to add all the feature requests (I only get time on weekends to work on it).
Few months back I got an opportunity to attend a design thinking workshop by Rakesh Sharma. Though I hardly got to apply it in my daily job, I was intrigued by the concepts and the process of ideation involved with design thinking.
In the pursuit of trying to prioritize features and understand what people really want, I pinged Rakesh for some help. He suggested a few things including interviewing users with JTBD (jobs to be done) approach.
This was great advice. Although at first I was reluctant to interview friends, but it was a nice experience and I had good data to work on. Something that helped me in these interviews was-
But then the pit fall is that people may feel the pressure. as they are on the spot. So to make it easy for them, you should remind them time to time that this exercise is not about judging them, but they judging your creation.
Alan Klement defines jobs to be done as a “be goal” instead of a “do goal”
A Job to be Done is the process a consumer goes through whenever she aims to change her existing life-situation into a preferred one, but cannot because there are constraints that stop her.
JTBD for JTB
As I am just a newbie at design thinking practices and specially JTBD thus my interpretation of the theory may be incorrect. As per my understanding and data from user interviews, the job to be done by all users is to “be productive”
This is “be goal” can then be achieved through multiple “do goals”. Few activities that users constantly tried to perform were —
- Format a string to JSON, edit a value and then convert back to string.
- Save edited/formatted JSON as a file
- Copy a specific part of a big JSON.
- Search through the data
First activity was interesting. This was a scenario when a programmer is trying to edit a mocked JSON. Steps involved were –
- Copy the string (with escaped characters) from code
- Formats it using a formatter
- Edit required value
- Copy formatted JSON
- Open a minifier (different URL)
- Paste formatted JSON and minify it.
- Copy string from minifier
- Paste minified string back in code
Steps 4 to 7 seemed very counter intuitive in this process. I was surprised that people were ok with this. To make this process fast in JTB, I added a button in formatter to copy minified string in a click. Thus converging 4,5,6 and 7 into one button click.
Without design thinking approach, it would have been difficult to know that this feature is required by multiple developers who work with a language that does not support JSON data natively.
I am still trying to work on all the feedback I have from different sources and I hope to be able to make JTB a product that helps developers “be productive” when working with JSON data.
This process of customer interviews and JTBD works better with more data points. So, if you are someone who regularly works with JSON and open for a quick 15–20 minute chat over a weekend then please let me know (DMs open sourabh_86) . It would be great to get some insights from a diverse set of users.