Case study · two 90-day engagements, 2019 – 2020Bugcrowd: a data strategy for a company that was two businesses at once
A two-sided business — companies on one side, security researchers on the other — sitting on years of data it wasn't using. Two 90-day engagements: the data strategy, then crowd management. Both built in full by Bugcrowd's own engineers.
- Client
- Bugcrowd, a crowdsourced security platform
- Engagement
- Two 90-day engagements, 2019 – 2020
- Our role
- Data strategy and crowd management strategy, with leadership
- Delivered
- Two strategies, a three-quarter roadmap, and the design of the data group
- Built by
- Bugcrowd's own engineers, in full
What Bugcrowd needed, and what stood in the way.
Bugcrowd is two businesses — a cybersecurity company that helps customers remediate threats, and a talent agency for the people who do it. Its systems treated them as one.
How the process ran, in ninety days at a time.
Two engagements covered steps one to four and handed over. Delivery and adjustment were Bugcrowd's own — it built both strategies with its internal team.
- 01
Define the business outcome
2019
Bugcrowd's leadership knew the platform served two very different populations. What it needed was the outcome stated in its own terms, and we wrote it with them. Run the customer business and the crowd business separately until they can converge. Build the data foundation both depend on. Become the gateway: the best talent for every program, and the best return on a researcher's time.
What we did
- The diagnosis: two lifecycles on one platform, and the imbalance between them
- The customer and crowd lifecycles, mapped side by side
- The outcome in writing, and the case for putting data on the product board's agenda
Bugcrowd hasA diagnosis leadership acted on, and an outcome in its own words.
- 02
Identify the people
2019
The people were already in the company. Bugcrowd's engineering team could do all of the work, so the question was ownership, not capacity. We mapped who should own the data on the customer side and who on the crowd side. We also recommended a standing data group of five, for leadership to staff from its own people whenever it chose.
What we did
- The map of who owns the data for the customer side and the crowd side
- A recommended data group, with each role defined, for leadership to staff in its own time
Bugcrowd hasIts own engineering team, which went on to build both strategies in full.
- 03
Measure and fix the process
2019
We measured where the data stood. Thirty requests were waiting and three were in progress, each taking two to four weeks, and most were a simple aggregation or a profile lookup. Reporting amounted to a renewal report and a time-to-triage figure, with definitions that changed from team to team. Every new question meant touching the platform.
What we did
- The request queue, measured: volume, wait, and what was actually being asked for
- The reporting inventory, and where the definitions disagreed
- The coupling between data and application logic, mapped
- The first four fixes, named: a normalized transactional model, a Postgres decision, an ETL spike, an operational data store
Bugcrowd hasA baseline, and the first four fixes to make.
- 04
Build what the business needs
2019 – 2020
We specified two strategies in enough detail for Bugcrowd's engineers to build them. The first was a data services framework. It gave the company one entity model and one set of master data, replaced ad hoc extracts with proper ingestion and export, and opened the data to programs so that new products and self-service reports stopped being tickets. The second was a crowd management strategy, built from first principles. It treated the crowd as talent with a lifecycle — recruit, onboard, produce, nurture — and added payout models beyond fixed rates and incentives that turn researchers into advocates.
What we did
- The data services framework and its three-quarter roadmap: infrastructure and a single source of truth first, a machine-learning-ready data services MVP after
- Feature specifications: a security knowledge base with a recommendation engine, Crowd Match with its mockups and information architecture, and auto-remediation with a build-or-buy decision first
- The crowd lifecycle, payout and incentive models, with requirements by stage across people, process and product
- The dashboards, drawn
Bugcrowd hasBoth strategies, built in full by its own engineers, with no follow-on engagement.
Bugcrowd built both strategies with its own engineers, in full. It never needed us again, and there was no second engagement to finish the first. That is the process at its smallest. We define the outcome, we specify the work, and the client's own team builds it — and the capability stays with them.