Drata
Scaling Risk Management for Enterprise
In just two years Drata established a dominant position in the Governance, Risk, and Compliance industry, but had done so focusing almost exclusively on Small and Medium Businesses. The next phase in its evolution was penetrating the Enterprise market in order to maintain its meteoric growth. This meant the Risk Management product had to grow from an ad hoc, pieced together solution to a cohesive, deeply thought out software suite. The problem was, outside of a few vague hypotheticals from leadership, there was no clear idea of what Enterprise-ready looked like. No one at the organization had ever conducted formal research on the product or its customers.
It fell on our team of six to validate the assumptions that had been included with the directive, build a comprehensive understanding of our existing and prospective Enterprise customer’s approach to Risk Management, and deliver compelling designs that we could scale over time.
So, how do you begin to tackle such a large project in a field bereft of any real standardized methodologies?
Research.
Initial Efforts
I began by analyzing years of Customer Success and Account Executive calls. From these I put together a detailed list of missing features, unmet needs, and competitor advantages that negatively impacted perception of the product and our ability to close deals. These calls revealed myriad Enterprise concerns with the current product, unique risk assessment needs we were simply unaware of, and a clear picture of the level sophistication expected. I then aggregated trends in this list to identify personas and create baseline wireframes in coordination with our Product Manager.
Follow-up calls with Customer Success and Account Executives helped refine understanding of these pain points and sales blockers. I began producing low-fidelity designs that were demoed at Product Department-wide calls. Customer support, product managers, and engineering leads all provided feedback and soon after we were ready to begin research in earnest.
Working closely with the PM, I conducted extensive calls and unmoderated tests with customers. I was able to see how organizations handled Risk assessment, reporting, and management across a multitude of divisions and product offerings. These insights were synthesized, correlated with earlier findings, and incorporated into the first round of prototypes.
RESEARCH
Discrete vs
Mixed Data Sets
One of the most critical requirements to evolving the Risk Management product to be Enterprise-ready centered around taking the experience from a single Risk Register to accommodating however many the user required. The determination we had to make was if the user could mix these registers in a single view or if we would limit them to viewing one at a time.
Through a series of customer calls, we learned that users greatly preferred a mixed register approach. In the Risk Management world, there truly is no single dominant method. Every organization assesses, categorizes, and treats risks differently. Therefore, being able to view and group registers in a way that reflected their specific methods was critical.
I worked closely with the engineers during the period, keeping them updated on user sentiment and where the research seemed to be leading. Concerns with legacy code and data architecture issues that might hinder our ability to execute the mixed register approach were raised. We began to incorporate more qualitative explorations to determine how critical the mixed approach was for the MVP. We were able to determine that users were willing to wait for a polished mixed experience if the single register they were familiar with received a number of achievable enhancements.
Ultimately, the single register experience was selected. This was predicated on assurances that the engineering team would continue to develop a mixed register solution and that management would prioritize this feature when it became available.
Discrete
Multiple
Nested
Inform, Don’t Overwhelm
RESEARCH
How to display these registers, regardless of the mixed versus single outcome, revolved around two primary approaches. One leveraged our card component which was immediately familiar to our customers and allowed for punchy data call outs. The other option was building a proper table component that met our needs. The added bonus to this approach was being able to contribute a component back to the library and unify the table experience across the entire application.
The key finding that reframed our understanding of our users’ approach to Risk Management, and immediately elevated the table as the correct route, was that the overwhelming majority relied heavily on Excel. Either they began their Risk Management program there and adopted Drata later or they supplemented feature gaps in our software with extensive spreadsheets. The freedom to sort and organize their data how they saw fit was prized above any data visualizations we put before them.
Ultimately, the spreadsheet insight proved to be far more functional. It could scale, it aligned with Enterprise needs, and was used quite extensively with SMB customers. We had the foundation for our Registers and a clear understanding of what capabilities would need to be included in the table component for the organization.
RESEARCH
Everyone Does Risk Differently. Truly.
Knowing we were using tables and knowing that users were coming from a spreadsheet experience, the challenge became selecting the baseline data for registers to display in the list.
This proved to be exceptionally challenging. There were no truly dominant data points that customers preferred. Some organizations had quarterly objectives and wanted data to inform them. Other organizations had weekly goals and priorities to monitor and wanted data points that reflected these. Some broke out registers by product, others be territory, still others by assessment readiness.
Once again, largely out of deference to milestones and keeping momentum, I recommended using the current baseline. We could leverage our user’s familiarity and spend our time more effectively developing a table that would let them decide how to evolve their experience beyond our baseline.
Going Beyond MVP
After research and iteration had concluded, the Risk team began development on the MVP. We were able to start the monumental task of meeting Enterprise needs without forgetting our small and medium businesses with a well informed, thoroughly tested foundation. Meticulous scoping with the Product Manager allowed us to manage expectations with management, our customers, and business partners. Additionally, with the foundation in place we were able to periodically conduct deep research into many of the niche, specific needs that come with Risk Management.
I also tested designs of future releases in order to continually validate conclusions we had drawn during the MVP process. A user research tool was also included in the design to capture any passive feedback our customers felt like contributing after each release.
Being able to introduce sophisticated features that immediately met the needs of Enterprise customers proved to be a huge win for Account Executives trying to woo larger Enterprise organizations. We had a foundation that scaled our product, and did so without alienating the existing small business customer base. It unblocked a number of other products that were in need of the deep feature capabilities of our table component. It also aided in the immediate short term by assuaging customers who had felt frustrated by the static, limited solution they had been using.
