Environment and Evidence: Mapping Technical Reality Before Proposing Solutions

Every presales engagement involves a moment where you propose something: a solution architecture, a demo scenario, a POV scope, a transformation roadmap. The quality of that proposal depends entirely on how well you understand the customer's current reality. Not the reality they describe in the first meeting, but the full picture: the technical environment, the organizational dynamics, the workarounds nobody talks about, and the political landscape that determines how decisions actually get made.

This is the E in VERTEX: Environment and Evidence. It follows Vision and Value because you need to know where the customer wants to go before you can assess where they are today. But without this element, Vision and Value is just aspiration. Environment and Evidence grounds the deal in reality.

The Two Parts: Environment and Evidence

Environment

Environment is the technical and organizational current state. It answers: "What does the customer's world look like right now?"

This goes far beyond "What's your tech stack?" You're mapping:

Technical architecture. What systems are involved in the workflow you're targeting? Where does data originate, where does it flow, and where does it end up? What integrations exist? What protocols and formats are in use? What's cloud, what's on prem, what's hybrid?

Operational reality. How does the team actually use the current tools? What's the daily workflow? Where are the bottlenecks? What manual processes fill the gaps between systems? What breaks regularly, and what does the team do when it breaks?

Organizational structure. Who owns the systems involved? Who uses them? Who maintains them? How does the team interact with adjacent departments? Who has influence over technology decisions?

Scale and constraints. Data volumes, transaction rates, user counts, geographic distribution, latency requirements, compliance mandates, security policies. These are the constraints that determine whether your solution fits or forces awkward workarounds.

Evidence

Evidence is the data that validates (or challenges) what stakeholders tell you. It answers: "How do we know this is true?"

Every champion has a perspective on what's broken and why. That perspective is valuable, but it's also filtered through their role, their frustrations, and their agenda. Evidence is what turns "our reporting process is slow" into "our compliance team generates 47 reports monthly, averaging 3.2 hours each, totaling approximately 150 person hours per month."

Evidence comes from:

• Quantitative data: Time studies, incident logs, performance metrics, cost reports
• Stakeholder validation: Confirming claims with multiple people. If the champion says the team spends 30 hours a week on manual reporting, ask the team directly
• Direct observation: Watching the current workflow in action, reviewing existing dashboards and tools, examining sample data
• Documentation: Architecture diagrams (even outdated ones), process documents, previous vendor evaluations, RFP responses

The discipline of gathering evidence prevents a dangerous presales failure mode: building your solution narrative on a single stakeholder's assumptions.

Why This Element Is Harder Than It Looks

Most SEs think they do current state discovery. They ask about the tech stack, note the major pain points, and move on to the demo. But there's a gap between surface level discovery and the kind of deep environment mapping that VERTEX requires.

The Polite Version Problem

In the first meeting, customers give you the polished version of their environment. "We run a modern cloud architecture with Kubernetes and a microservices approach." What they don't mention: three legacy systems that can't be retired because critical processes depend on them, a data pipeline that runs on a cron job someone wrote five years ago, and a shadow IT spreadsheet that's become the de facto source of truth for half the team.

The real environment only reveals itself when you ask specific, technical questions and demonstrate that you can handle the messy answer. "Walk me through what happens when a new compliance regulation is added. Where does the requirement enter your system, and how does it propagate to all the affected reports?" That kind of question surfaces the workarounds, the gaps, and the hidden complexity.

The Political Landscape

Technical architecture is only half the environment. The other half is political: who has power, who has influence, who has concerns, and whose priorities matter most.

Mapping the political landscape means understanding:

The economic buyer. Who controls the budget? What do they care about? How do they make purchasing decisions? What have they approved or rejected recently?

The technical gatekeeper. Who has veto power over technology decisions? What are their criteria? Are they an ally or a skeptic? What would win them over?

The champion. What's their real motivation? Career advancement, problem solving, organizational influence? How much internal capital are they willing to spend on this initiative?

The blocker. Who benefits from the status quo? Who sees this initiative as a threat to their domain, their team, or their preferred vendor? What would it take to neutralize their opposition?

This information rarely comes from a single conversation. It emerges across multiple discovery sessions, through questions asked in different ways to different people.

The Honest Gap Assessment

One of the most valuable things you can do in Environment and Evidence is identify where your solution doesn't fit perfectly. Maybe your platform doesn't support a specific integration the customer needs today. Maybe your deployment model requires a cloud migration they haven't budgeted for. Maybe your pricing model doesn't align with how they manage operational expenses.

Documenting these gaps honestly serves two purposes. First, it builds enormous credibility. When you say "Here's where we're strong and here's where we'll need to work together on a solution," the customer trusts everything else you say more. Second, it lets you address gaps proactively rather than having them surface as objections during the evaluation.

The Outputs: Architecture Summary and Stakeholder Map

Environment and Evidence produces two artifacts that become reference documents throughout the deal.

The Current State Architecture Summary

This is a concise document (one to two pages) that captures:

1. System landscape. The key systems involved, their roles, and how they interact
2. Data flows. Where data originates, how it moves between systems, and where it's consumed
3. Integration points. Existing integrations, protocols, and any middleware or ETL processes
4. Constraints. Security requirements, compliance mandates, performance requirements, and deployment restrictions
5. Known gaps. Where the current architecture falls short of the customer's needs

This document serves as the foundation for your demo environment design. If your demo environment mirrors the customer's architecture, the demo feels like a preview of their future state rather than a generic product tour.

The Stakeholder Map

A simple grid that captures:

| Stakeholder | Role | Priority | Influence | Sentiment | |---|---|---|---|---| | Sarah Chen | VP Operations | Reduce manual work, real time visibility | High (budget authority) | Positive, driving the initiative | | Marcus Rivera | IT Security Lead | SOC 2 compliance, data residency | High (veto power) | Neutral, needs technical validation | | David Park | Compliance Analyst | Faster report generation, fewer errors | Medium (end user) | Very positive, experiencing daily pain | | Jennifer Liu | CTO | Platform consolidation, scalability | High (final approval) | Unknown, hasn't engaged yet |

The sentiment column is critical. Knowing who's supportive, who's skeptical, and who's unengaged tells you where to invest your energy. The "unknown" entries are especially important because they represent risk. A stakeholder with high influence and unknown sentiment is the most dangerous person in the deal.

Evidence Gathering Techniques

The "Show Me" Approach

Instead of asking customers to describe their current process, ask them to show you. "Can you walk me through how you generate a compliance report today? I'd love to see the actual workflow." Watching someone navigate through three systems, copy data into a spreadsheet, manually apply formatting rules, and email the result to their manager reveals ten times more than a verbal description.

In remote settings, this means asking for a screen share. Most customers are willing if you frame it as: "The more we understand about how your team works today, the more relevant we can make the demo and the POV."

The Adjacent Stakeholder Interview

Your primary contact gives you their perspective. But talking to the people adjacent to the process gives you the full picture.

If the champion is the compliance manager, ask to speak with:

• The IT team that maintains the systems feeding data into the compliance process
• The analysts who execute the daily workflow
• The VP who consumes the output and makes decisions based on it
• The security team that governs what tools can be used

Each conversation adds a layer of evidence. The compliance manager says reporting takes too long. The IT team reveals that the data pipeline is fragile and breaks every time there's an update. The analysts describe three manual workarounds they've built. The VP says they don't trust the numbers because of known data quality issues.

Now you have evidence from four sources that all point to the same conclusion, but each from a different angle. That's powerful.

The Quantification Question

Always push for numbers. "You mentioned the reporting process is time consuming. Can you help me understand the scale? How many reports? How often? How many people involved? How many hours per report?"

Customers don't always have precise data, and that's fine. Estimates are valuable. "Roughly how long would you say...?" or "If you had to guess, how many hours per week does your team spend on...?" Most people can give a reasonable ballpark, and a ballpark grounded in evidence is infinitely more useful than a vague "it takes too long."

These numbers flow directly into the value engineering work that builds the business case.

The History Question

"Have you tried to solve this before? What happened?"

This question surfaces critical deal intelligence. If the customer tried a similar solution three years ago and the implementation failed, you need to understand why. Was it a technology problem, an adoption problem, or a political problem? What's different now? Who was involved then that's still involved today?

Past failure is both a risk and an opportunity. It's a risk because the organization has scar tissue that makes them cautious. It's an opportunity because you can specifically address what went wrong and show how your approach avoids those failure modes.

Environment and Evidence in the VERTEX Sequence

This element receives its direction from Vision and Value: you know what the customer wants to achieve, so now you're mapping the reality that your solution needs to navigate.

It feeds directly into the next three elements:

Risk and Readiness uses the architecture summary and stakeholder map to identify technical, organizational, and political risks. A fragile data pipeline is a technical risk. An unknown CTO is a political risk. A team with change fatigue is an organizational risk.

Trajectory and Transformation uses the current state as the starting point for the roadmap. You can't plan a credible transformation without understanding where you're starting from.

Evaluation and Experiment uses the environment details to design a POV that reflects the customer's real conditions: their data, their integrations, their scale. A POV conducted in a generic environment proves nothing about whether the solution will work in their environment.

The evidence you gather here also feeds back into Vision and Value. Sometimes what you learn about the environment reshapes the objectives. The customer thought they needed a new reporting tool, but the real problem is a broken data pipeline that corrupts the data before it reaches any tool. The environment reveals the actual problem that needs solving.

For a ready to use bank of discovery questions organized by stakeholder role and deal stage, download the free Discovery Sprint Question Bank. And for the complete Environment and Evidence methodology, check out Modern Presales. covers current state mapping and evidence gathering in depth.