The 5 Questions Every Discovery Session Must Answer
I once walked into a customer engagement where the organization had already selected the SIEM it wanted to buy.
The product had been researched.
The vendor had been identified.
The customer believed the technical decision had effectively been made.
There was only one problem:
The organization had not clearly defined what it expected the SIEM to accomplish.
The conversation began with products, features, ingestion rates, integrations, dashboards, and licensing. But beneath those discussions were more fundamental questions that had not been answered.
What problem was the organization actually trying to solve?
Which systems and data sources needed to be visible?
Who would investigate the alerts?
What operational outcome would define success?
What would happen after the platform was deployed?
The customer had selected a technology before fully defining the problem.
That is not unusual.
Customers frequently enter discovery with a preferred product, an existing vendor relationship, a budget estimate, or a list of features copied from a requirements document.
Those things provide useful information—but they do not replace discovery.
Effective discovery must answer five questions.
What Problem Are We Actually Solving?
The first answer is rarely the complete answer.
“We need a SIEM.”
“We need SD-WAN.”
“We need better security.”
“We need to move to the cloud.”
These are solution categories, not problem statements.
The technical pre-sales professional must uncover what is driving the request.
- Is the organization missing critical visibility?
- Is the current platform too expensive to operate?
- Are analysts overwhelmed?
- Is growth exposing an architecture that no longer scales?
- Has an audit, breach, acquisition, outage, or leadership change created urgency?
Until the underlying problem is understood, there is no reliable way to determine whether the proposed solution is appropriate.
Why Does The Problem Need To Be Solved Now?
Urgency reveals priority.
A project connected to a compliance deadline, expiring contract, acquisition, security incident, or major expansion will be evaluated differently from an initiative based primarily on general improvement.
Understanding “why now” helps establish:
- The real timeline
- The cost of delay
- The internal priority
- The availability of resources
- The consequences of missing the deadline
If there is no compelling reason to act, the opportunity may be interesting—but it may not be real.
What Happens If Nothing Changes?
Every proposed investment competes with other demands for money, people, and attention.
The customer must be able to explain the cost of maintaining the current state.
That cost may include:
- Continued operational inefficiency
- Security exposure
- Compliance risk
- Lost revenue
- Analyst burnout
- Poor customer experience
- Inability to scale
- Increasing technical debt
The goal is not to manufacture fear.
The goal is to make the consequences visible enough for the organization to make an informed decision.
What Does Success Look Like?
“Successful implementation” is not a meaningful success criterion.
A product can be installed correctly and still fail to produce the expected business or operational outcome.
Success must be defined in observable terms.
For example:
- Reduce investigation time from hours to minutes
- Establish visibility across all critical systems
- Support expansion from 18 to 54 locations
- Consolidate multiple management platforms
- Meet a specific compliance requirement
- Reduce alert volume without sacrificing coverage
- Provide executives with measurable risk reporting
When success is defined before the solution is designed, architecture decisions become more defensible—and post-sale expectations become far easier to manage.
Who Must Agree That The Problem Has Been Solved?
Complex technical decisions are rarely made by one person.
Security, networking, infrastructure, operations, finance, procurement, legal, executive leadership, and end users may all evaluate the project differently.
A technically correct solution can still fail when stakeholders have conflicting expectations.
Discovery must identify:
- Who owns the problem
- Who will operate the solution
- Who controls the budget
- Who evaluates technical risk
- Who can block the decision
- Who will ultimately declare the project successful
Technical alignment without stakeholder alignment is incomplete.
These five questions create the foundation for everything that follows:
Discovery → Assessment → Architecture → Validation → Executive Alignment → Implementation Planning → Success Measurement
The purpose of discovery is not to collect enough information to prepare a demonstration or proposal.
It is to create enough shared understanding to make the next decision intelligently.
Customers rarely buy technology.
They buy confidence in the outcome.
Real-World Use Case
Scaling Security and Connectivity Across A Rapidly Growing Healthcare Organization
A multi-location urgent-care organization was expanding rapidly—from approximately 18 locations to 54 locations across the Eastern, and Midwestern United States.
Its existing network and security environment had not been designed for that pace of growth.
The challenge was not simply to replace a firewall or introduce a new connectivity product. The organization needed an architecture that could support expansion while improving security, visibility, operational consistency, and resilience.
The resulting solution combined:
- Palo Alto Networks firewalls (Customer Owned)
- Cortex Prisma SWG/SRA
- Cortex Prisma SD-WAN
- Managed Threat Detection and Response by AT&T
- A vendor-assisted proof of concept
- Professional Services for Implementation
The architecture addressed more than the immediate technical requirements. It created a repeatable model that could be extended as new locations came online.
The engagement grew from approximately $45,000 to $95,000 in monthly recurring revenue and resulted in a three-year renewal.
The lesson was not that one product won.
The lesson was that the architecture aligned security, connectivity, operations, growth, and implementation around a shared outcome.
That is the difference between selling components and designing a solution.