Watch and ask your user, it is never enough
Innovators like me love thinking about new products, services and business models that might help the company grow and bring more value to our users. However, daydreaming about this great product that is going to change the market comes with a hell lot of assumptions which sometimes we don’t even realize of. Not only we assume people need or like our product, but we assume how and why our users do their jobs. Bypassing what we think is known and not asking enough why’s places us in the loop of spending money and time on ideas that should have been discarded in the first place. In this post I will be writing about how I managed uncertainty and discovery in some projects to find out what our users want and how they expect our digital products to behave.
Some months a go, I was assigned to a project for improving an online service that provided information to our clients about dangerous pests for their crops. The service relied on information provided by collaborators and technicians in the field who could count the amount of bugs, eggs, etc. of specific pests and send the information to us so that we could aggregate it and then publish it. My task was to redesign the service and create a better user experience for the tool.
As you can imagine, this tool had two main users: technicians (people who send the info) and our clients (people who buy our products and are interested in receiving notifications about pest pressure). I received lot of feedback and information internally about how the app should work and what kind of information it should display. However, I decided to take two approaches to validate our assumptions and make sure we were creating the tool our users were expecting and was valuable to them. I will write about the one I used for technicians, expect a future post with the Focus Group for clients too :)
Watch what they do
Technicians are skilled professional who usually work in the field. They walk by many plots during the day and they are capable of recognizing pests in early stages. But how exactly do they do the counting process? Do they write something down? Do they use their phone or a tablet? Or maybe they just use a paper. If so, are they following any template? How do they send the date to us? Do they aggregate any information?
They key about being a good Product Manager is asking questions and discover pains for your user. The best way to do so is by getting out of the office to the real environment where your product should be used and make questions about their activities. Lots of questions actually. So I went exactly where this process was happening, ready to ask and learn about their daily routine.
After a day in the field recording every move and asking pretty much all the time, I could answer many of the questions and assumptions I had in my mind. They usually visited fields in group, splitted in rows and used paper sheets with a common template with cells. They would mark cells if they found presence of a bug and then they counted how many crosses they had to write it in paper. When they came back home, they would open the same template in Excel and they filled everything again. They saved it and then sent it to an email address of our IT provider so that they could manually extract data and then aggregate it. Something I was wondering all the time is why they did not use any digital mean to report or write what they saw. The answer was simple: writing in paper cells is fast, internet connection is usually weak in rural areas and mobile screens are difficult to be seen when you are in a field with sunlight.
With just one day asking, I got essential requirements for my product. In fact, they were willing to try something new, but it had to be fast, visible and had to work offline. I also asked them if I could help them writing down the data in the paper sheet, so that I could really understand what ‘fast’ meant when it comes to writing and preparing assessments. Sometimes I would also get my phone and check at the screen. They were so right: when you are under the sun in the middle of a field is almost impossible to see what’s on your screen. Only bright interfaces with clear buttons and contrast work.
After my day in the field, I went back to the office with a deep understanding of what our users do, suffer from and need. I could now transform it into requirements, constrains and user stories with almost zero uncertainty about how and what should be built. However, as agile has thought us, testing and getting feedback is never enough. During the development process I always kept them in the loop, so that they could try and validate design, also in the field.
My final advice here is: get out of your office, go ahead and watch, talk to your users. There are plenty of digital tools and plugins you can add to your website to record live sessions of your users to learn what they do, what they need and what frustrates them. Try to reduce your uncertainty and validate your assumptions all the time. It is never enough.
