Why GTM Systems Projects Fail Before Development Begins

Most GTM systems projects do not fail because the developers could not build the solution.

They fail because the organization began building before it had achieved enough clarity about what needed to be built, why it mattered, how the business should operate, who owned the process, what other systems were affected, and how success would be measured.

By the time those problems surface during development, UAT, or launch, they are considerably more expensive to resolve.

I have seen versions of this problem throughout my career working across Salesforce, Revenue Operations, business systems, cybersecurity, enterprise technology, CPQ, forecasting, integrations, lead management, customer success platforms, and broader GTM transformation.

Whether the project involves Salesforce, CPQ, HubSpot, Marketo, Gainsight, Clari, DocuSign, ERP integrations, territory management, lead routing, or another part of the revenue technology stack, the underlying pattern is remarkably consistent:

The technology exposes the ambiguity that already existed in the business.

A strong GTM systems project therefore begins well before development.

It begins with clarity.

1. Problem Definition: What Are We Actually Trying to Fix?

A stakeholder saying:

“We need Salesforce to do this.”

is not a problem definition.

Neither is:

“Sales needs a better process.”

Those are starting points for discovery.

One of the most important responsibilities of a Business Systems Analyst, Product Manager, RevOps leader, or systems architect is separating the requested solution from the underlying business problem.

A stakeholder may request another Salesforce field.

But why?

Perhaps sales management cannot forecast accurately.

Perhaps Finance requires information that sellers are not consistently capturing.

Perhaps an integration is not passing the appropriate data downstream.

Perhaps the field already exists elsewhere and the real issue is adoption.

Perhaps the business process itself is undefined.

Building the requested field may technically satisfy the ticket while doing absolutely nothing to solve the problem.

Before discussing configuration or development, I want to understand:

• What business problem are we solving?
• Who experiences the problem?
• What happens today?
• What is the business impact?
• How frequently does it happen?
• What behavior or outcome should change?
• Why does the organization need to solve it now?

That distinction prevents teams from becoming highly efficient at building the wrong thing.

2. Stakeholder Discovery:

Find the People Who Actually Understand the Process

Systems projects frequently begin with an incomplete stakeholder list.

Sales Operations may sponsor the project.

But Sales may execute the process.

Finance may control approvals.

Legal may influence contracting.

Deal Desk may manage exceptions.

Marketing may generate the originating data.

Customer Success may inherit the account.

IT may manage integrations.

Executives may consume the resulting forecast.

A GTM system is rarely owned by one function even when one department technically administers the platform.

That is why stakeholder discovery matters.

The goal is not simply to schedule more meetings. It is to identify who makes decisions, who performs the work, who receives the output, who controls exceptions, and who will be affected downstream.

There is another important distinction:

The executive sponsor understands the objective.

The frontline user often understands the reality.

You need both.

A VP might describe how the process is supposed to operate.

A sales representative, Deal Desk analyst, or operations manager can often explain what actually happens when a customer needs an unusual contract structure at 4:45 p.m. on the final day of the quarter.

That is where many critical requirements are discovered.

3. Current-State Process: Understand Reality Before Designing the Future

Organizations frequently want to jump directly into solution design.

That is dangerous.

Before designing a future-state system, I want to understand the existing operating environment.

Not merely the Salesforce screens.

The entire process. Incidentally, this is also why I love creating process maps. From and To – the Target.

Consider quote-to-cash.

A quote may begin in Salesforce but then move through:

Salesforce → spreadsheet → Slack → email → Finance → Legal → DocuSign → ERP → billing.

If the project team looks only at Salesforce, most of the actual process remains invisible.

Current-state discovery should identify:

• Systems involved
• Manual steps
• Decision points
• Approval paths
• Data handoffs
• Ownership
• Exceptions
• Workarounds
• Duplicate data entry
• Bottlenecks
• Shadow systems
• Downstream dependencies

This is where process mapping becomes extremely valuable.

One of the lessons I have carried across multiple organizations is that the system diagram and the business process diagram are not the same thing.

Both matter.

4. Future-State Operating Model: Define How the Business Should Work

This is one of the most overlooked stages of systems implementation.

Teams often move directly from:

Current problem → technical requirements

when there should be another step:

Current problem → future operating model → technical requirements

Technology should enable an operating model.

It should not invent one.

Before asking how Salesforce should behave, determine how the business should behave.

For example:

Who owns an opportunity at each stage?

When is an opportunity considered qualified?

Who can approve discount exceptions?

How should channel deals operate?

When should Finance become involved?

Which system owns pricing?

What happens when a contract changes mid-term?

What happens when the standard process does not apply?

What information must exist before the opportunity can advance?

If those questions remain unresolved, developers eventually end up making business-policy decisions through configuration.

That is backwards.

A developer should not have to decide your company’s approval philosophy because nobody else did.

5. Requirements: Translate Business Intent Into Buildable Logic

Once the problem and operating model are understood, requirements become much stronger.

A good requirement bridges three worlds:

Business intent → process behavior → technical implementation

This is where experienced business systems professionals provide significant value.

Consider:

“Sales wants automated approvals.”

That is not enough.

We need to understand:

• What triggers approval?
• Which attributes determine the approver?
• Are thresholds based on discount percentage, dollar value, product, region, customer type, or another dimension?
• Are approvals sequential or parallel?
• What happens when an approver is unavailable?
• Can a previously approved quote change?
• What happens if pricing changes after approval?
• Who can override the process?
• What needs to be captured for auditability?

Now we have something developers can actually build.

Good requirements remove unnecessary ambiguity while preserving the business objective.

They also distinguish between:

Must have

Should have

Could have

Without prioritization, every stakeholder requirement eventually becomes “critical,” which usually produces an unnecessarily complex system.

6. Dependencies:
No GTM System Exists in Isolation

One of the fastest ways to underestimate a systems project is to treat a platform as an island.

Salesforce may sit at the center of the GTM ecosystem, but it frequently interacts with:

• Marketing automation
• Product systems
• Data enrichment
• Lead routing
• CPQ
• Contract management
• ERP
• Finance
• Customer Success
• Data warehouses
• BI platforms
• Support systems
• Identity and access management

An apparently small Salesforce change can therefore have consequences far beyond Salesforce.

Change an opportunity field and you may affect:

• Forecasting
• Dashboards
• integrations
• validation rules
• automation
• reporting
• downstream data models
• user permissions
• territory logic
• API consumers

I have worked in environments involving platforms such as Salesforce, Marketo, HubSpot, Gainsight, Clari, DocuSign, Oracle, and other components of the revenue technology stack.

The recurring lesson is simple:

Dependencies discovered during design are manageable. Dependencies discovered during production incidents are expensive.

Dependency analysis should happen early.

7. Success Metrics:
Define “Better” Before Building It

Another common failure pattern is launching a system and then debating whether it worked.

That happens because success was never defined.

“We implemented CPQ.”

“We launched the new workflow.”

“We migrated from Marketo.”

“We rolled out the new CRM process.”

Those statements confirm delivery.

They do not confirm business success.

A better conversation asks what changed because of the implementation.

Depending on the project, metrics might include:

• Quote turnaround time
• Approval cycle time
• Forecast accuracy
• Lead response time
• Conversion rate
• Data completeness
• Manual touches per transaction
• Routing accuracy
• User adoption
• Support tickets
• Exception volume
• Renewal visibility
• Sales productivity
• Time spent correcting downstream data

The metrics do not need to be perfect.

But the organization should establish a baseline and define what improvement looks like before launch.

Otherwise the project risks measuring completion rather than value.

8. UAT Strategy:
Testing Is Not a Final Checkbox

User Acceptance Testing is often treated as something that happens at the end of development.

I view it differently.

The UAT strategy should begin during requirements.

Why?

Because asking:

“How will we prove this requirement works?”

often exposes weaknesses in the requirement itself.

Effective UAT is not simply clicking through the happy path.

It should validate:

• Core workflows
• Business rules
• Roles and permissions
• Integrations
• Approval paths
• Negative scenarios
• Exceptions
• Boundary conditions
• Downstream impacts
• End-to-end business processes

For example, testing that a quote can be created is useful.

But real business testing may also ask:

• What happens with a multi-year agreement?
• A co-term?
• An unusual discount?
• A product combination that should not be sold together?
• An amendment?
• A territory change?
• A failed integration?
• An approver who is unavailable?
• A user without the expected permission?

These are the scenarios that determine whether the system works in production.

UAT is therefore not merely quality assurance.

It is business validation.

9. Change Management:
A Technically Correct System Can Still Fail

You can build the correct solution and still have an unsuccessful implementation.

Why?

Because systems do not generate value by existing.

People must use them correctly.

Change management should therefore begin long before launch.

Users need to understand:

• What is changing
• Why it is changing
• When it changes
• What they are expected to do differently
• Where to get help
• What happens to the old process

Depending on the implementation, this may involve:

• Training
• Documentation
• Quick-reference guides
• Office hours
• Manager enablement
• Release communications
• Champions
• Feedback channels
• Support processes

Incidentally, I have always considered documentation particularly important.

A good system implementation should not exist only in the heads of the people who built it.

Process knowledge should become institutional knowledge.

That becomes especially important when teams change, administrators leave, systems evolve, and Version 2 arrives a few months later.

10. Post-Launch Measurement:
Go-Live Is the Beginning of the Next Phase

Many project plans treat go-live as the finish line.

Operationally, it is closer to the beginning of the next phase.

Production reveals things that controlled environments cannot fully replicate.

Users behave differently.

Edge cases appear.

Volumes change.

Data exposes patterns.

New business requirements emerge.

Some assumptions prove wrong.

That is completely normal.

The question is whether the organization has created a mechanism to learn from it.

After a deployment launch, I want to know:

• What is working?
• What is not?
• Where are users getting stuck?
• Are people following the intended process?
• Are they creating workarounds?
• What defects are appearing?
• What requests are actually enhancements rather than defects?
• Are the original success metrics improving?
• What belongs in Version 2 or Version 3?

Strong systems organizations treat implementation as a lifecycle:

Discover → Design → Build → Test → Launch → Measure → Improve

not:

Build → Launch → Move On

BOTTOM LINE: The Real Work Happens Before the Build

Developers are often blamed when systems projects struggle.

Sometimes development is the problem.

But frequently the developer was handed an incomplete problem, conflicting stakeholder expectations, undefined business rules, unclear dependencies, weak acceptance criteria, and a deadline that assumed all of those questions had already been answered.

At that point, development becomes expensive discovery.

That is one of the most costly ways to run a transformation program.

The stronger approach is to invest more heavily upstream.

Define the problem.

Understand the stakeholders.

Map the current state.

Design the future operating model.

Translate it into clear requirements.

Identify dependencies.

Define success.

Design UAT.

Prepare users.

Measure what happens after launch.

Then build.

Because the most successful GTM systems teams are not simply good at configuring technology.

They are good at creating organizational clarity before technology turns that clarity into software.

And that is often the difference between a system that technically goes live and a system that actually improves the business.