GTM Fundamentals · intermediate · node 2.6
The buying journey
Prerequisites
Most founders and GTM leaders design funnels backwards. They start with the product timeline: “We want them to see value in week 2. We want a decision in week 4. We want to go live in week 6.” Then they build a funnel that tries to move prospects through those stages.
This is wrong. The funnel does not move at your pace. It moves at the pace the market moves. The buyer’s journey is determined by how they actually buy, not by how your product wants them to buy.
The buying journey is the sequence of decisions and commitments a buyer moves through from first awareness of a problem to signature of the deal. It is not linear. It stalls, reverses, loops back, and sometimes dies. Understanding the journey your market actually takes—and where it gets stuck—is the foundation of everything downstream: motion design, messaging, team structure, and economics.
The diagnostic matrix: where journeys differ
The shape of the buying journey is determined by four dimensions. Every market lives in a cell of this matrix, and the cell you are in predicts the journey structure:
| Dimension | Impact on Journey | Low Complexity | High Complexity |
|---|---|---|---|
| Deal size (ACV) | Determines approval speed and stakeholder count | <$50k: 1 decision-maker, 1-2 week cycle | >$500k: 3-5 stakeholders, 4-8 week cycle minimum |
| Buying committee size | Determines alignment cost and decision velocity | Founder or IC makes choice alone | Committee requires 3-4 consensus rounds |
| Implementation complexity | Determines proof-of-concept timeline | Zero setup required; value immediate | Requires migration, integration, training; 4-12 week POC |
| Organizational maturity of buyer | Determines procurement formality | Early-stage, informal, gut-driven | Mature, process-heavy, requirement-driven |
A company selling a $20k/month tool to a startup CTO has a 2-week journey: problem → exploration → decision → go-live. The same company selling the identical tool to an enterprise banking platform has a 6-month journey: problem → business case → RFQ → vendor evaluation → procurement → legal → procurement revision → CFO approval → contract signing → implementation planning → go-live.
The product is identical. The journey is completely different because the buying context is completely different.
The journey stages: where deals stall
Every buying journey has predictable stages. Not every deal reaches every stage. But the ones that do stall in the same places:
Stage 1: Problem recognition and severity
The buyer does not start trying to buy something. They start experiencing a problem. A system goes down, a process breaks, or pain accumulates until it reaches criticality. This stage is not about your product. It is about whether the buyer recognizes the problem is expensive enough to solve.
What stalls journeys here: The status quo is acceptable. The problem is real but not painful enough to justify a change. If you are selling to a bank with a 20-year-old payment processing system, the pain is obvious: integration is nightmare, throughput is limited, latency is high. If you are selling to a company with a functioning (though slow) system, the pain is diffuse: it costs 2% more than a better solution would, but no single transaction is blocking. The probability of progression depends on whether the cost of the problem exceeds the cost of inaction.
Different for each buyer type: An engineer experiences the problem as “my workflow is broken.” A manager experiences it as “my team is not efficient,” or worse, “I cannot measure efficiency.” If the manager does not feel the pain, the engineer’s problem stays personal and never escalates to a buying journey.
Stage 2: Problem validation and solution exploration
The buyer has recognized the problem. Now they need to understand whether solutions exist, and what they cost. This is where they begin research: talking to peers, reading comparisons, looking at vendors. This stage moves quickly if the solution category is known (CRM, payment processing, analytics) and slowly if the category is new or poorly understood.
What stalls journeys here: The solution space is confusing or fragmented. If there are 40 vendors claiming to solve the same problem, the buyer gets lost in choice overload. If the solution requires foundational changes (moving from on-prem to cloud, replacing infrastructure), the buyer realizes the problem is bigger than they thought and defers. If peers warn of implementation pain, the buyer downgrades the urgency of the problem.
Different for each buyer type: An engineer explores solutions by trialing products, reading docs, and asking peers on Slack. A manager explores by attending demos, reading case studies, and asking sales reps for benchmarks. A CFO explores by asking “what do other companies in our size/industry pay?” The information sources are opposite, and the proof that moves them forward is opposite.
Stage 3: Internal stakeholder alignment
The buyer has found a solution they like. Now they have to convince everyone else who touches this decision that it is worth buying. For a $20k deal with one buyer, this stage does not exist. For a $500k deal with 4 stakeholders, this stage is 40% of the total cycle time.
This is where most deals die.
What stalls journeys here: Stakeholders have conflicting incentives. The COO wants speed; the CTO wants safety. The user wants easy; the CFO wants cheap. The champion wants best-of-breed; the procurement team wants lowest price. The internal committee becomes the real sales motion, not the vendor.
The deal now requires 3-4 consensus loops: what is the actual problem we are solving? Does this vendor solve it? Is it worth the cost? Can we implement it? Alignment on any one of these moves the deal forward. Misalignment on any one stalls it.
Different for each buyer type: An engineer champion has to convince a manager that the solution is worth the disruption and risk. A manager champion has to convince finance that the ROI justifies the cost. A procurement officer has to convince a CTO that the vendor is secure and reliable. Each stakeholder is playing defense against a different risk.
Stage 4: Budget justification and approval
The internal committee has aligned that the solution is worth buying. Now comes the question: can we afford it, and do we have approval to spend? For startups, this is a “do we have $50k left in the budget?” conversation. For enterprises, this is a multi-month process that intersects with fiscal calendars, budget cycles, and capital allocation across the entire business.
What stalls journeys here: Budget does not exist in the current fiscal year, and the company only budgets annually. Approval is gated on headcount limits or cost-center spending caps. The deal landed in the wrong budget cycle (June instead of January). Finance wants proof the investment will generate X% return, but the buyer cannot quantify that.
This stage is invisible to most salespeople until it suddenly appears. The deal feels close, then suddenly the prospect says “we need to wait for next year’s budget.” Or “we need CFO approval, and he only meets quarterly.” Or “the deal has to go through procurement, and they have a three-month evaluation process we cannot bypass.”
Different for each buyer type: A technical buyer often has no idea how budget approval works. A financial buyer knows the calendar and can navigate it. The champion has to do the work of getting internal approval, and if they do not have the political capital or the information to make the case, the deal stalls.
Stage 5: Vendor evaluation and proof of concept
Now the real evaluation happens. The vendor wants to prove the product works. The buyer wants to prove it will not break anything. This is where implementation complexity becomes visible. A two-week free trial works when the product delivers value in 48 hours. A two-week trial fails when the product requires a week of setup before value appears.
What stalls journeys here: The proof of concept takes longer than expected. Integration requires custom work. Setup reveals hidden complexity. The buyer realizes implementing this solution is more disruptive than they thought. Other priorities emerge and the POC timeline gets stretched. The team that will implement the solution is not available or is not confident in the tool.
This is also where deals die for legitimate reasons. The vendor claims the product solves the problem. The proof of concept reveals it does not, or it solves it only at a cost (training load, integration pain) that is not worth it.
Different for each buyer type: An engineer POC focuses on integration, data accuracy, and performance. A manager POC focuses on workflow change, user adoption risk, and ROI proof. A CFO POC focuses on data security and vendor stability. The same product is being tested in three different ways by three different evaluators.
Stage 6: Contract and legal negotiation
The proof of concept succeeded, and now it is time to negotiate terms. For a small deal ($10-50k), this is a phone call and a signature. For a large deal ($500k+), this is a 4-8 week process that involves legal teams, security reviews, data processing agreements, compliance certification, and often multiple revision rounds.
What stalls journeys here: Security requirements reveal compliance gaps. The buyer’s legal team has 47 redlines on the contract. Your company is not SOC 2 certified yet. The contract requires liability caps your company’s investors will not approve. The deal was a handshake at the executive level, but now procurement and legal are raising issues the executive did not anticipate.
Many deals move backward in this stage. The prospect says “we love the product and the price, but legal will not sign this contract,” and suddenly the deal is back with your VP of Sales and their CFO negotiating terms.
Different for each buyer type: A technical buyer has no leverage in this phase. A procurement officer has maximum leverage. A legal team can grind out a 12-week process if they are cautious. The champion who had authority to approve the deal now discovers they do not have authority to commit to the contract terms.
The non-linear journey: loops, reversals, and stalls
The journey does not progress stage-to-stage in a straight line. Real deals look like this:
- Prospect is in Stage 3 (internal alignment). Executive champion leaves the company. New executive does not believe in the solution. Journey goes backward to Stage 2.
- Prospect is in Stage 5 (POC). POC shows the product will require more integration than expected. Journey reverses to Stage 4 to request budget for implementation services.
- Prospect is in Stage 4 (budget approval). The deal was gated on the fiscal year, but the VP who championed it got promoted and lost focus. Deal enters a waiting loop until the next budget cycle, 9 months away.
- Prospect is in Stage 2 (solution exploration). Prospect discovers competitor is also evaluating the same vendor and wants to see independent assessment. Journey loops back to Stage 1 (problem severity) while both competitors align on the actual problem.
The real journey is messier than any funnel chart. Deals get stuck not because there is friction in the process, but because the buying context changes: budgets, champions, priorities, or competitive situations.
Asymmetric journeys: engineer vs manager
Consider the same deal from two vantage points. A software company is selling developer infrastructure.
Engineer’s journey:
- Discovers problem through painful workflow (Stage 1)
- Tries free tier, finds value in 2 hours (Stage 2)
- Advocates internally to teammates (Stage 3 — informal)
- Requests budget from manager, gets $5k approval in a Slack message (Stage 4 — informal)
- Sets up integration in 4 hours (Stage 5 — POC is zero)
- Adds to tooling stack; teammate joins via free tier 2 weeks later (expansion)
Total cycle time: 2-4 weeks. Cost of buying motion: <$5k. Friction points: none.
Manager’s journey:
- Hears complaint from engineer team that developer productivity is low (Stage 1 — problem is heard second-hand)
- Requests vendor landscape analysis or RFQ from procurement (Stage 2 — time-consuming)
- Gets estimate from three competing vendors (Stage 2 — extended)
- Builds business case and ROI analysis to justify spend (Stage 4 — significant work)
- Submits to budget cycle or requests capital allocation (Stage 4 — formal approval)
- Initiates procurement process with security and compliance review (Stage 5 — 4-8 weeks)
- Negotiates MSA and DPA with vendor (Stage 6 — 2-4 weeks)
- Arranges rollout and training (Stage 5b — post-signature)
Total cycle time: 4-6 months. Cost of buying motion: $50-100k in internal effort. Friction points: 7.
These are opposite journeys in the same company for the same product. If you design a funnel that assumes the engineer journey and your buyer is actually a manager, you build features and messaging for an outcome that never happens.
What causes journeys to die permanently
Some deals enter the funnel and never exit. They are not stalled; they are dead. Understanding why matters for funnel design.
Problem was not real. During exploration, the buyer realizes the problem they thought they had is not as expensive as they assumed. The status quo is acceptable. They stop engaging.
Solution was not the one they wanted. During evaluation, the buyer discovers a competitor’s solution that better fits their workflow, even if it costs more. Or a build-vs-buy analysis reveals they can solve it with an internal tool.
Internal champion lost power or left. During stakeholder alignment, the executive sponsor got distracted, demoted, or left the company. The deal loses its advocate and dies in committee.
Budget cycle closed or shifted. During approval, the fiscal year ended, or capital was allocated elsewhere. The deal waits for next year’s budget and never re-enters the pipeline.
Implementation cost exceeded ROI. During POC, the buyer realizes the disruption of implementation exceeds the value. The project is de-prioritized in favor of other initiatives.
Competitive loss. During evaluation, a competitor wins the deal or the buyer decides to build internally.
Regulatory or compliance change. During legal review, new compliance requirements make the implementation impossible without additional work. The deal is postponed indefinitely.
Buying context changed. During any stage, mergers, reorganizations, leadership changes, or market shifts change the buyer’s priorities. The deal becomes less urgent than other initiatives.
These are not funnel leaks to fix. These are outcomes to predict and accept. If your market structure means 40% of deals die due to budget cycles, you do not fix it by improving messaging. You accept it and build retention and expansion mechanics for the 60% that do close.
Founder mistakes: assuming all deals follow the same path
The most common founder error in funnel design is assuming all deals follow the same journey. It looks like this:
You have a motion that works brilliantly for small deals ($10-50k) with technical buyers. You close 20% of trials in 4 weeks. You assume this scales linearly. You hire more salespeople and expect them to hit the same conversion and cycle time metrics.
But your salespeople discover that some of the pipeline they are working is $200k deals with procurement requirements and 6-month cycles. Or they are selling to managers who need business cases, not engineers who need product value. Or the buyers are in regulated industries where every deal requires a security review.
The metric collapse. Conversion drops from 20% to 8% because the motion that works for small technical deals does not work for large enterprise deals. Cycle time stretches from 4 weeks to 16 weeks because the buying committee requires consensus. ACV seems to grow, but blended quota carry becomes 40% because half the pipeline does not fit the motion.
The founder now has two choices:
-
Segment the funnel. Acknowledge you have two different buying journeys. Build two different motions: one optimized for small technical deals, one optimized for large enterprise deals. Hire two different types of salespeople. Measure them separately. Accept that they have different unit economics.
-
Pick one and dominate it. Stop trying to sell to both small technical and large enterprise buyers. Choose one, optimize that funnel completely, and leave the other on the table.
Most founders instead try to force one motion into both journeys. They end up with a motion that is mediocre for both. This is not a sales execution problem. This is a funnel architecture problem.
The rules of funnel design based on journey understanding
Once you understand the actual journey your market takes, you can apply these rules:
Rule 1: Map the journey first. Before designing funnel stages or metrics, interview 20 customers who have bought and map how they actually bought. When did they realize they had a problem? Who did they talk to first? How long between decision and signature? What stalled the deal? The journey map is your baseline.
Rule 2: Funnel stages are not linear progress. Your funnel should reflect the actual journey, including loops, reversals, and waiting stages. “In evaluation” is not a single stage; it has engineer evaluation, manager evaluation, legal review, and POC scheduling happening in parallel. Build that into your metrics.
Rule 3: Different buyer types require different funnels. If you have two different buyer journeys (engineer vs manager, startup vs enterprise, buyer A vs buyer B), build separate funnels. Measure them separately. Do not blend them.
Rule 4: Friction is sometimes the right answer. You see deals stalling at Stage 4 (budget approval) and assume you should remove friction by offering payment plans. But if your market’s buying process requires annual budget cycles, offering payment plans does not help; it confuses the buyer because they cannot spend incrementally against next year’s budget. The friction is structural, not operational. Accept it and design your metrics and messaging around it.
Rule 5: Measure stage duration, not just conversion. A 20% conversion rate from stage 1 to 2 sounds good until you realize stage 2 lasts 12 weeks because the buyer is waiting for budget allocation. Your sales team is unblocked; the buyer’s organization is not. Measure how long deals sit in each stage and where they loop back.
Rule 6: Identify the point of maximum leverage. Every journey has a stage where friction removal gives the highest return. In startup journeys, it is Stage 2 (make the product value obvious in 48 hours). In enterprise journeys, it is Stage 3 (make internal alignment faster by providing ROI proof). In procurement-heavy journeys, it is Stage 6 (pre-draft contract terms that procurement teams recognize). Find your leverage point.
Rule 7: Accept what you cannot change. If your market is regulated and all deals require a security review, you cannot make that stage faster through messaging or sales training. You can only make it less painful (provide audit reports upfront, pre-fill compliance questionnaires). Design around the unchangeable.
Teaser to the next chapter
Understanding the buying journey tells you what pace the market moves at. But it does not tell you what message moves the journey forward at each stage. You now know when a buyer is likely to be receptive to a decision. You need to know why they are receptive, what information they need, and what proof moves them forward.
That is the job of messaging and narrative. Different buyer types need different messages at different journey stages. A message that moves an engineer from Stage 1 to Stage 2 (try the product) is useless to a manager at the same stage (manager needs business case first). The wrong message at the right time can actually reverse the journey—moving the buyer from Stage 3 back to Stage 2 because you did not address their concern.
Next chapter: how to match your message to both the journey stage and the buyer type.
Key takeaways
- The buying journey is shaped by market structure, buyer type, deal size, and organizational complexity—not by your product's go-live timeline.
- Different buyer types (engineer vs manager) have opposite journey structures; the same deal looks like two different sales processes from two different vantage points.
- Journeys stall at predictable stages: problem recognition, solution exploration, internal stakeholder alignment, budget justification, contract negotiation, and post-signature implementation.
- Founders assume all deals follow the same path; they do not. Asymmetric journeys for different buyer types and market segments require different funnel architectures.
- Funnel design is diagnostics first: map the actual journey, identify where deals die, then decide whether to remove friction or accept that this market does not fit your motion.
Related concepts
How to cite this
@misc{shalvi_gtm_fundamentals_the_buying_journey_2026,
author = {Singh, Shalvi},
title = {The buying journey},
year = {2026},
url = {https://shalvisingh.com/gtm/fundamentals/the-buying-journey},
note = {GTM World Model — GTM Fundamentals}
} Singh, Shalvi. "The buying journey — GTM Fundamentals." shalvisingh.com, 2026. https://shalvisingh.com/gtm/fundamentals/the-buying-journey