A Journey from Coding to Focusing on User Needs
I remember in the 3rd year of my Bachelor’s Degree at the University of Oslo, we had to do a group project that involved partnering with a software company to interview one of their customers. The objective of the project was to observe the customers doing their work with the software program, and produce a report to the company highlighting potential problems in their workflows and how they could make enhancements to simplify the lives of their users or help solve additional problems for the user. I’ve always enjoyed solving problems, but at the time I was very much focused on the coding challenges as part of the program. In particular I loved a good algorithm or data structure problem to dig into. I did not have much empathy or understanding of the end user, and unfortunately I have to say I found the project pretty tedious.
As I started my career as a software engineer, I was quickly corrected in my perception that everything was about the code and the computer science aspect of the problem. I remember a heated discussion one time with members from a few cross-functional groups where we were arguing about which function was the most important for the company. My argument was that without the software engineers you wouldn’t have a product to sell, but it was quickly dismissed by one of the sales team members as he pointed out that without the sales and marketing groups, the software engineers wouldn’t have jobs as nobody would be buying whatever they built.
So I learned relatively quickly that building a good product requires teamwork to reach the customer. But it wasn’t until about a decade into my career when I made a career change to move from Engineering into Product Management that I realized the importance of focusing on user needs. One of the first things I did was to attend Pragmatic Marketing training after a friend recommended it as a good way to get up to speed on my new Product Management responsibilities. The message was effectively that all product development efforts should trace back to the customer problem, and that in order to have a successful product we needed to focus on problems that were “pervasive," “urgent," and that customers would have a “willingness to pay” someone to solve their problem. That was an ah-ha moment for me when I came to the realization that not just myself as an engineer, but the whole company I was working for at the time, spent so much time and effort figuring out “how” to build something, but very little effort was done to discover “what” was worthwhile to build. Our practice was typically to talk to a few large customers with a lot of feature requests, and then try to prioritize them into a backlog, and then 6-12 months later a solution would come out that sometimes solved the problem for one customer, but more often than not it missed the mark completely and there was very little market demand for the features. Talk about a recipe to end up with a product bloated with features but very hard to use. I tried to change our ways by sending all the Product Management people in our business unit through the same training, and while we made some forward movement, the inertia of the big and bureaucratic organization was too much to overcome and we only had mediocre success in making the company more customer and market focused.
Fast forward a bit and I am now with Censys, a startup company focused on mapping the attack surface of enterprises to help them uncover risks and unknown exposures, and ultimately help protect their infrastructure and customer data. We have applied the Pragmatic Marketing principles of being a market driven company, and most of the features we undertake have been vetted with customers. Our UX and product team had a call last week with a customer. The objective of the call was to validate some design prototypes to make sure that what we developed could support their desired workflow and allow them to quickly find the information they are after. At one point the customer shared his screen and walked us through an investigation he was doing based on a risk highlighted by our product. It quickly became clear that our product was not providing the customer the information he needed to complete his investigation. Essentially our UI showed the customer the timestamp from when our database process ran instead of the time when the scan operation was actually made, resulting in confusion and wasted time for the customer. Now that we have seen the problem first-hand with the customer, we will address the issue in the next sprint, helping all our customers who might be facing the same problem. And in a full-circle moment for me personally, what was 20 years ago a tedious project of customer observation has now become the most exciting part of the job. By seeing the problem first hand, we can build something truly meaningful to help the customer do their job better rather than just build something because we think software development is fun (which we do). Here is a screenshot of the updated design with the new timestamp:
I am very excited about the traction we are seeing with our product at Censys and the interactions with our customers to help guide our product to be useful in their daily jobs. As we just raised our Series A we will be adding additional UX research and Product Management people to make sure our product is even more focused on solving real customer problems. And don’t forget the moral of the story: Just because you’re 20 years old and think you know everything, don’t knock what you learn in school, it might actually be valuable. That way maybe you can shorten the 15 years it took me to understand the value of user research and ensuring the problems you solve meet real user needs.
-Eirik Herskedal | VP Product @ Censys