Egress Security Centre

Summary

Egress is a Saas company in the Cyber Security space and specialises in email. The big opportunity in the market is phishing and the huge costs of security breaches from companies whose staff fall victim to these attacks.

This creates an opportunity to develop tools to mitigate this risk. Demand is high, especially from sectors where data security is a high priority like Health, Law and Financial Services.

The Problem

Competitors were gaining an advantage in the market by introducing detailed reporting and analytics to their product set. This was a problem during the sales cycle and a strategic product differentiator.

We had a number of legacy technical barriers to implementation and no clear understanding of how to report on a complex product outcome.

Understanding

Getting to grips with the complex data requirements and the nature of our architecture was essential to understand what we could deliver now and in the future.

I took the lead to:

• Bring teams together to discuss what was missing technically.
• Talk to customers about the most important areas to be reported on.
• Talk to sales people about what held us back in the sales cycle.
• Assess competitor products, what were the incumbents doing vs the innovators.
• Ideate how we could move forward.

What I learned:

• Customers mainly wanted to be able to report the tool worked to their board and show they were taking steps to mitigate a problem and it was working.
• It was clear that what we created for the sales cycle would also be a huge benefit in retaining existing customers by proving product value and spreading that deep into board rooms.
• Delving into our product in such detail raised many more questions and insights about our customers and our products. Reporting on our customers had led us to report more deeply on ourselves and our products!

Validation

Research and discovery had given us a clear problem to solve: "Show the product works" so I began to iterate on ways to create a product dashboard that could be easily and safely shared into board meetings.

Our research had identified two distinct user groups,

• The administrator who was interested in dealing with day to day risk.
• The CISO who was interested in how effective the product was and what the risk was to the business at a point in time.

We iterated numerous versions in response to user testing results, stakeholder review, new information from customers and our technical discovery. This was a complex road of continued technical discovery and evolving customer expectations coupled with new teams and processes bedding in.

We eventually arrived at a first phase design which was compelling to the customer, achievable technically and fed into the long term vision.

I continued to push on how we capture customer feedback on an ongoing basis by starting to introduce product analytics and continuous discovery tools & processes.

Results

• A project which had failed on 4 separate occasions in the last 4 years had gone live.
• The sales team no longer reported that reporting requirements were a factor in losing sales deals.
• The foundation was in place to turn our greatest weakness into our greatest strength.

Growth & New Problems

• Our research was constantly throwing up the suggestion from customers that they disliked remembering the different places they needed to go to manage their Egress account and reporting.
• We had acquired other products.
• Managing and maintaining separate applications was inefficient.

We needed a way for customers to see across all 4 products but also use those individual products to identify risk patterns between them. Making the suite more valuable together. A project informally code named 1+1 = 3.

I took the lead on:

• Designing and bringing together these two interfaces into one,
• Revamping our design system to 2.0 to take this new era into account.
• Designing how we could introduce self serve to help us scale.
• Guiding the project from ideation & technical review to C-suite approval.