HE
Let's create
Cyber ​​projects

Cyber6Gill

More Projects:

The Company &
the Product

CyberSixGill was a young cybersecurity startup when we first started working with the company. It has since been acquired by the American cybersecurity company BitSight.

The company developed a cyber intelligence platform that scans the Deep Web and Dark Web to surface relevant threats against organizations. These threats may include leaked executive credit card details, exposed login credentials, or published access permissions to organizational systems such as Active Directory.

By turning hidden external intelligence into actionable insights, the platform helps security teams detect risks earlier, understand their business impact, and respond before they escalate.

Project Goal

From High Touch to Low Touch.

CyberSixGill’s product configuration process was handled almost entirely by Customer Success, because the setup flow was too complex and expert-oriented for standard customers to complete on their own.

The company’s CPO believed this could be changed through a self-service configuration experience. The goal of the project was to rapidly prove that a standard customer could configure the product independently, with minimal support from Customer Success.

If successful, the proof of concept would justify a dedicated development effort and help the company move toward a more scalable onboarding model.

The Challenges

Complex Self-Service Configuration

Challenge 1

Complex Self-Service Configuration

The product configuration process was long and complex, requiring customers to define a wide range of organizational assets, such as names, IP addresses, servers, computers, credentials, and other sensitive data.

The complexity was even greater because not every customer needed to configure the same assets. Each organization had different needs, which made it difficult to create one clear, guided setup flow that could support all relevant scenarios without overwhelming the user.

Challenge 2

Expert-Oriented Setup Interfaces

The existing configuration interfaces were originally built quickly for expert users — mainly internal engineers and Customer Success teams who handled the first beta installations.

As a result, the setup experience was not suitable for standard customers. It required deep product knowledge, familiarity with the configuration logic, and external guidance in order to complete the process successfully.

Challenge 3

Scaling Beyond Customer Success

Because the setup process was too complex for customers to complete independently, configuration depended almost entirely on Customer Success.

As the company grew and gained more customers, this created a scaling problem: every new customer added more operational load to the CS team. To support the company’s expected growth, the product had to move from a high-touch setup model to a scalable self-service experience.

Executive Solution Summary

Executive Solution Summary

CyberSixGill’s initial product setup was handled almost entirely by Customer Success, using internal interfaces designed for expert users. As the company grew, this high-touch setup model became a bottleneck and a barrier to scale.

Although the configuration process was widely perceived as too complex for customers to complete on their own, the CPO challenged this assumption and initiated a focused effort to prove otherwise.

Through a Design Sprint, we built a Figma prototype within two weeks: a flexible self-service wizard that allowed standard customers to configure the product independently, reducing dependency on CS and supporting scalable onboarding.

The screenshots shown here are from the system experience we continued to define and design over the following year, following the success of the initial self-service concept.

Our Process

Group 1707478609
Group 1707478739 (1)
Group 1707478819 (1)

Interviews and Analysis

Since there were no customers who actually performed significant configuration, we interviewed the CS people who perform the process for the customers and interact with them on the subject.

We mapped the time wasters and the pain and friction points.

After that, it was easy to define the goals and barriers.

01
02

Solution Concept & Prototype Development

On the second day of the Design Sprint, participants explored inspiration from complex self-service processes, generated new ideas, and selected the strongest direction.

The result was a flexible wizard-based concept designed to guide customers through configuration step by step. During the following week, we built the prototype in close collaboration with the CPO and the product manager leading the initiative.

Prototype Validation and Research Limitation

As in every Design Sprint, we ended the process by testing the prototype. In this case, the testers were members of the Customer Success team, who had deep familiarity with the configuration process and with customer pain points.

Their feedback helped us validate the flow, identify gaps, and refine the wizard before moving forward. However, this was also a research limitation: ideally, the prototype should have been tested with real customers, not only with internal experts.

This insight became an important reminder that even when internal stakeholders understand users well, true validation requires testing with the actual audience who will use the product independently.

03

The Solution

Flexible Self-Service Wizard

The solution was a flexible wizard designed to guide customers through the configuration process step by step, without forcing them to complete everything in one continuous flow.

Users could move back and forth, skip irrelevant sections, pause the process, collect missing data, and return later to continue. For example, if they needed an Excel file with all company IP addresses, they could leave the wizard, gather the data, and upload it when ready.

What surprised us most was how much simpler the process became once it was structured around the user’s real workflow.

Validated, But Not Developed

The prototype successfully proved that customers could configure the system independently through a guided self-service experience.

However, the wizard was not developed as a dedicated product initiative. Although the concept solved a clear scaling challenge, the product team chose to prioritize other areas, such as developing features that created stronger competitive differentiation and a clearer product moat.

In retrospect, especially considering the company’s later exit, this decision appears to have been a valid strategic trade-off: scaling the setup process was important, but not necessarily the highest-value investment at that stage.