Cross-product integration

The 2 products operated on fundamentally different security philosophies. Randori Recon was a "red-team" tool: it thought like an attacker, probing for weaknesses before they could be exploited. QRadar Suite was a "blue-team" tool: it thought like a security team defending their own systems, monitoring known threats to these systems, and responding to active incidents. Their users had different mental models, different definitions of success, and different day-to-day workflows.

Together, they could be a powerful product. That opportunity would only be realized if the 2 product teams could align on how to get there. But because it was a new acquisition, most stakeholders understood only fully understood one product and its domain, but not both. Without a shared foundation, decision-making and the integration timeline was stalling, with no plan in sight.

My job was to help sort the confusion and get everyone up to speed and on the same page quickly so that the real work could begin.

If we were going to make any progress, I needed every technical and non-technical stakeholder to have a shared understanding of both products. Presenting feature lists or technical documentation, without context, was not going to work on an audience with such different backgrounds. I needed something that would make the distinction between the 2 products immediately clear and memorable.

I developed learning materials with illustrated analogies to make the abstract concrete for everyone.

I then zoomed in closer to show how each tool would evaluate the same asset, like a single window, differently, and the nuance of how they detect threats.

To get the story right, I ran these analogies by people not on the project and used their feedback to iterate the illustrations until they were simple enough to convey these core concepts to anyone. When I shared these with both product teams, it instantly clicked.

With a shared foundation in place, I turned to the central challenge: how do you structure a complex integration decision so that 2 product teams can align quickly and move forward with confidence?

I developed the framework by consulting engineers, PMs, and architects from both teams—mapping what was technically feasible, what each product could realistically support, and where the integration opportunities lived within QRadar Suite's UI. This approach respected the complexity of the decision while still giving teams a clear basis for moving forward in a "choose your own adventure" style.

I recommended Path A+B+C as the North Star knowing that time and resources would likely make a phased approach necessary. My framing of full UI integration as the destination meant that earlier iterations could be designed and shipped with the complete vision in mind, rather than as standalone solutions that would need to be reworked later.

To make the paths tangible, I created workflow maps showing how the 2 products would interact and where integration would occur across the user journey. I then paired each path with mid-fidelity mockups, so stakeholders could evaluate what each option would actually look like in practice, rather than speculate about it in the abstract.

With the framework in hand, the 2 product teams diverged to conduct their own, deeper discovery—examining questions like technical feasibility across different codebases, which Recon features were most valuable based on customer feedback and analytics, and what API integrations would actually require.

I then designed and facilitated a 3-day MVP workshop for 24 cross-functional participants from the integration team. I structured the workshop to build progressively toward an executable plan of action, moving from problem definition and Hills—an IBM method for defining and aligning on the problem being solved—through ideation, MVP scoping, metrics definition, and a six-month cross-functional delivery plan.

But managing the room was its own design challenge. Debate was heated, particularly during the Hills exercise, with participants digging into technical positions and arguing in circles rather than converging. At one point I wrote on the board, "Hills are for inspiration, not for dying on". This earned chuckles from the room and became our motto for the rest of the workshop.

As counterproductive as these conversations initially were in the context of the workshop, and despite our new motto, the integration team insisted they liked to work this way.

So, rather than cutting conversations short, I made an agreement with the group: I would flag where we were against the schedule and the goals we had set for the week, and they could decide whether to keep talking or move on. Giving them ownership over that decision kept trust in the room and back on track faster than a hard stop would have.

In the end, the team aligned on a blend of my proposed paths A and B (data enhancement and workflow integration) as their MVP, with an agreement that Path A+B+C was the ultimate goal, validating my framework by combining paths in a way that matched their available resources and phasing needs.

My strategic design work in the initial planning phase had a direct impact on how quickly and confidently the 2 teams could move towards integration. By the end of my involvement, the teams had:

• A shared vocabulary for a complex decision. The four paths gave stakeholders language to describe what integration could actually look like—whether external, hybrid, or fully native—and what that would mean for customers and the bottom line.
• Realistic conversations about scope and value. For the first time, leadership could weigh the resources required against the value to IBM and its customers, rather than discussing the integration in the abstract.
• Concrete product thinking. The framework grounded discussions in specifics: if and how to surface unknown assets, what information to show users, and how to communicate red-team concepts clearly for a blue-team audience
• 3+ months saved. A projected three-quarter timeline became a ready-to-build MVP in less than 6 months with concrete metrics and a cross-functional delivery plan.

My research surfaced opportunities that extended well beyond the feature integration itself.

The integration created a natural opportunity to raise the quality of QRadar Suite as a whole: adopt Recon's stronger patterns for explaining complex concepts, and use the integration as an opportunity to standardize fragmented technical terminology across the platform.

I framed the acquisition as a chance to improve the entire platform, not just add a feature. By folding these improvements into the existing integration work, we could maximize impact with minimal extra resources. I advocated for these opportunities in stakeholder reviews, and the highest value items were incorporated into the MVP.