Uncovering deep problems

OVERVIEW

A prospective but large customer told his sales representative that while they liked our product, it wasn’t giving them the information they needed to accomplish their job.

THE USER

Michael worked hard to automate his security team’s workflow, but as a Director of Security, he still needed to address many cases personally and individually. When doing investigations, he would complain that he wasn’t getting enough information in our app to get his job done.

STRATEGY AND DISCOVERY

I began by defining a user-based outcome we would shoot for alongside the Product Manager (PM) and Engineering Team Lead (ETL). With that as our north star, we diagrammed out all the user flows we believed our users would take and where they would need to leave our product to get the information they were looking for.

I analyzed our gaps in knowledge and ran a discovery interview with Michael. We filled many of those gaps and developed a priority for which categories were the most important based on some stack ranking exercises Michael did for us that we then compiled into an overall score.

IDEATION

Reviewing all we had learned with the entire product team, including engineers and PM, I held a workshop to facilitate exploring the idea space from a diverse set of perspectives. After synthesizing those ideas into a first draft of designs, it was time to take it back to Michael for feedback.

RESULTS

The initial impression was very positive. The parting words from Michael were, “If you could release these designs, that would be very helpful for us.” He was now bought into the product and ready to sign. However, a big twist changed how I would have proceeded with the product had I had more time.

THE TWIST AND WHAT I WOULD HAVE DONE NEXT

During the interview, the user said something that completely changed how I viewed the project. He said that finding the person in charge of fixing the individual problems was their biggest problem.

We had been focusing on helping them to know where the risk was located and how to fix it, but those were both secondary to the actual problem. We recently heard a quote from a customer saying, “I am a trained security professional who spends more than half his time acting as a lost-and-found operator.” Sometimes, you must hear the same thing several times before it sinks in.

If I had the time to keep moving on this project, I would have pitched solving this higher-level problem. It would have involved creating a new type of user. Team leads could sign up for the platform and be assigned IP ranges/DNS/services they were responsible for. Newly found risks could be auto-assigned if they belonged to a group. That would let the security team focus only on the risks that fell outside easily defined boundaries, giving the team more time to do their job.