Product Design Manager / Senior Product Owner
During this project, I spent a lot of time coaching and/or leading efforts in a variety of areas: conducting initial research, interaction design, socializing / getting buy in on the final scope, and usability testing.
ThreatQ is a threat intelligence platform that allows a Security Operation Center (SOC) within an organization to take external threat intelligence (which hacking groups are leveraging which hacking tools to exploit which vulnerabilities) and apply it over their internal network to determine the overlap.
Organizations use this data overlap to assess where they could be vulnerable and better understand how to handle certain situations.
A SOC is often seen as a cost center within a company. It’s hard to quantify all of the times your organization was NOT attacked because of all the hard work put into establishing a secure environment. Furthermore, there are only so many hours in the day, so the team wants to make sure they are prioritizing their time appropriately.
We believe that by building a simple, yet flexible, solution for customers to visualize their data will allow teams to illustrate success while also allowing them to rally behind a shared set of priorities.
Chase use cases/workflows instead of competitors
We knew we needed to shift the business’ thinking from “checking a box to say we have the feature” to solving a real problem for customers. We achieved this by incorporating customer feedback early on in the process.
Leveraging previous work saves money
As a team, it’s important to build a catalogue of takeaways from research. Because of this, we had a jump start on the project and it sped up the recruiting process.
Prototypes are powerful influencers
Both UX and development prototypes were used to steer the conversation around effort vs. value with the business. Ultimately, I think we chose the right scope and our customers have been thanking us for it.
Our new design process is working!
In 2019, our team revamped our process to better incorporate customer feedback. This gives the team a better feel for which problems to solve and the ability to gauge the effectiveness of our solutions. Customer enthusiasm is high and our dashboards have a lot of traction.
Workflows over features
Even though our initial release has been positively received, we are still continuing to gather customer feedback and make improvements. Our new dashboard capabilities have highlighted other inefficiencies in our application that we are actively looking to address.
A Note About Process
Agile development has undoubtedly been the most popular and prevalent way to manage engineering teams throughout my career. Over the years, I’ve participated in a lot of variations of Agile development and have a firm grasp on pitfalls to avoid, things that work well, and things that don’t.
Agile development, a concept often misused to devalue prep work
I’ve written about this in the past.
If you’ve worked in the industry for even a small window of time, there is no doubt in my mind that you’ve heard the mantra “Fail Fast, Fail Often”. It’s an often misunderstood phrase, sputtered dogmatically, in an attempt to debunk any sort of prep work to meet a desired outcome.
After all, why try to predict the outcome when we could quickly build something and test it.
This largely makes sense… caveated with two things:
- The team needs to have a strong understanding of the problem
- The needs to have the means to validate if their solutions are effective
These days solid design work isn’t an option. It’s mandatory.
At the beginning of 2019, we renewed our dedication to infusing our product planning and design processes to customer feedback with each step.
Before starting a project at ThreatQ, we do the following:
- Review feature requests that have been submitted by customers in our idea portal
- Review support issues that may somehow involve a similar piece of functionality
- Identify potential candidates for our research studies
- Gather information from our team of sales engineers who may have helpful information from the field
For this particular project, we’ve concluded our Discovery Phase with the following:
After doing some initial research, we came to the following conclusions:
- Each customer has their own unique combination of threat intelligence data. This data comes from a mix of internal and external sources.
- There are commonalities in how the data is structured, however, each team leverages it in different ways to match their security goals.
- Our platform was built to be flexible enough to fit a variety of scenarios. Because of this, we found that some security teams were struggling with how to move forward after initial setup. We’ve defined this as the “where to start” problem.
- Threat Analysts need the ability to quickly assemble a view that explains their security posture on a particular topic.
- SOC Managers would love the ability to demonstrate the value their team provides to the business through the lens of threat intelligence.
These points helped us articulate the value of the project…
Value For Customers
- With a dashboard custom tailored to meet the goals of the team, it removes the anxiety around “where to start” analysis work.
- Threat Analysts will now be able to build the data visuals needed for reporting.
- SOC managers can build dashboards for their team to gather around to track overall success.
Value For The Business
- The ability to build customizable dashboards is a common RFP requirement. Because of this, we were losing a chance to be evaluated as a potential solution.
- Our competitors offer a solution in this space, some with more robust solutions than others. We’ve consciously scoped our variation of dashboards to be timely to the market while maximizing customer value.
- Because our sales engineers can leave each prospective customer with a dashboard, it will aid team adoption of our platform and demonstrate its value from day one.
• • •