Here is what transfers completely: diagnosis. An individual describing why they want coaching, or any high-ticket outcome, is exactly like a company describing its problem, which is to say the stated problem is almost never the real one. "I need more interviews" usually decomposes, on examination, into a conversion problem three stages downstream. The discipline of decomposing the funnel, of getting the prospect's own numbers on the table and reading them together against benchmarks, works identically. I have built discovery instruments for B2C that are structurally the same tool I used on seven-figure enterprise deals: capture what the person actually said, play it back, and let the facts make the diagnosis undeniable. People do not argue with their own numbers, and that is true whether the person is a CFO or a job seeker.

What also transfers is qualification, and this is where most B2C operations are weakest. Enterprise discipline says some deals should not be pursued, and the polite, prompt no is a professional obligation. High-ticket B2C, done honestly, needs the same rule more, not less, because the buyer is spending personal money on a personal outcome. Selling to someone the program cannot help is not an aggressive sale. It is a small betrayal, and it also, less nobly, destroys the referral economics the whole model runs on.

Now the differences, and the first one restructures everything: there is no committee, which means there is no place for the emotion to hide. In enterprise deals, feelings are laundered through process; fear of a bad decision becomes a security review, ambition becomes a business case. The individual buyer has no such machinery. The fear and the hope are right there in the conversation, undiluted, because the stakes are personal in a way no enterprise deal ever is. A company that buys wrong loses budget. A person who chooses wrong loses months of a finite career. The seller's job in that room is closer to fiduciary than persuader, and behaving otherwise is both wrong and, over any horizon longer than a quarter, bad business.

Which is why the most important discipline I carried over is expectation-setting, tightened rather than loosened. The temptation in B2C is the happy path: lead with the best outcome anyone ever got. I refuse that, structurally. Sell against averages. Show the distribution. Say out loud what the program does not fix. Every incentive in a commission-driven room pushes the other way, and resisting it is precisely what makes the eventual yes durable; a client sold on the median does not churn when reality arrives, because reality was the pitch.

The tempo is the last difference, and it cuts both ways. B2C cycles are short, which means feedback is fast, which means the craft improves weekly instead of yearly; a bad discovery habit that hides for two quarters in enterprise shows up by Thursday in B2C. But short cycles also tempt shortcuts, pressure tactics, urgency theater, the countdown timer. The enterprise seller in me finds those not just distasteful but amateur: pressure closes deals and prevents customers.

Selling to companies taught me process. Selling to people taught me what the process was always for.

I do not say this with contempt. Memory-based operating is the natural state of every company, and in the early years it is even efficient; the founder's recall is fast, free, and mostly right. The trouble arrives with scale, and it arrives quietly, in a specific and recognizable pattern: the same decision gets made three different ways depending on who is in the room. That sentence, more than any dashboard metric, is the diagnostic. When I hear it inside a client, I know what we are going to find.

What we found inside one manufacturer makes the pattern concrete. A factory chasing five points of line efficiency, each point worth roughly a million dollars a year. The data existed, in the sense that hourly production numbers were written on paper sheets, but a bottleneck took an hour and a walk of the floor to find, downtime repair math was unknowable because start times were flagged from memory, and management steered off a weekly email. Every decision on that floor was made against information somewhere between an hour and a week old. When data is late, money is late. The five missing points were not an effort problem. They were the compound interest on latency.

The prescription in these situations has a name that makes executives reach for their wallets prematurely: a data layer. So let me define it at its real size. A data layer is whatever makes decisions observable instead of remembered. Sometimes that is cameras and edge computing feeding a supervisor an alert in under sixty seconds. Just as often it is embarrassingly smaller: a pipeline where every deal has a stage, an owner, and an exit criterion, so "where is this deal and why" is a lookup rather than a meeting. The technology varies. The property being purchased is the same: shared, timestamped, contestable facts.

Contestable is the important word. The deep cost of memory-based operating is not the individual bad call; it is that the calls cannot be audited, and therefore cannot be improved. When decisions leave a trail, what was known, what was chosen, what happened next, the organization gets access to its own history for the first time. Arguments change species: instead of whose recollection wins, the fight is over what the record shows, and that fight, unlike the other one, produces learning. A digital audit trail sounds like compliance furniture. It is actually how an operation acquires the ability to notice its own patterns.

For anyone wondering where to start, the sequencing rule I use is simple: instrument the decision that is made most often, by the most different people, with the most money per occurrence riding on it. Not the biggest decision; the most repeated one. Repetition is where variance lives, variance is where memory does its damage, and one well-instrumented decision that the team actually consults will outteach a warehouse of reports nobody opens.

Companies love to describe themselves as data-driven, and mostly they are recollection-driven with dashboards. The distinction is not the volume of data. It is whether, at the moment of choosing, the chooser is looking at the world or remembering it.

Here is what the money actually comes from, in roughly ascending order of how often it gets ignored.

Error cost is the first layer under the headline. Manual processes do not just run slow, they run wrong at some rate, and in operational workflows each error has a price: a payback, a rework loop, an angry partner, a compliance exposure. On one program the explicit target was holding error paybacks under half a million dollars a year, which tells you the errors were the business case before speed ever entered the room. Automation buys consistency, and consistency has a dollar value you can compute from last year's mistakes.

Ramp time is the layer below that, and it is the one I have almost never seen in a vendor's ROI model. A process that lives in people's heads takes months to teach; on one operation, four to six months before a new hire mattered. That number is a tax on growth, on turnover, on every reorg. When the process moves out of heads and into a system, the ramp does not shrink. It largely stops existing as a concept, because there is far less to transmit. The hiring plan, the training budget, and the fragility of the team all reprice at once.

Then there is the redeployment layer, which is where the strategic value lives. Teams drowning in a manual queue are not just slow, they are unavailable. The backlog behind them, and there is always a backlog behind them, goes untouched for years. On that same program the client had a dozen initiatives waiting, including contract reviews and audits they sized as a seven-figure problem, unreachable because the queue never emptied. The most valuable output of the automation was not the minutes saved on the process. It was the team, returned to the work only the team could do.

Getting these layers, though, depends on discipline that most automation efforts skip, so let me name the two that matter most. First: prove the workflow manually before automating it, because automation applied to an undiagnosed process just produces the wrong answer faster, at scale, with confidence. Second: define acceptance in writing before anyone builds. What counts as testing, what counts as production, what turnaround and quality thresholds trigger acceptance, who signs. The programs that die in pilot purgatory, and most do, die precisely here, in the gap where "it works" means one thing to the builder and another to the buyer. Written gates are unglamorous and they are the difference between a demo and an operation.

There is also an honest accounting to do on the other side of the ledger: automation buys a maintenance obligation, an integration surface, and a new dependency, and anyone who prices it at zero ongoing cost is selling something. The point is not that automation is cheap. The point is that its value is mostly not where the headline says.

So when the deck says hours to minutes, ask the three questions underneath: what did the errors cost last year, what does ramp time do to your growth math, and what has the backlog been waiting on. That is the business case. The minutes are just the demo.

He is not an exception. Every elite tennis player travels with a coaching box. Chess grandmasters employ seconds. Olympic sprinters, who run in a straight line for ten seconds, have technique coaches. And the surgeon Atul Gawande wrote a famous essay about hiring a retired surgeon to observe his operations; the coach found twenty minutes of improvements in the first session, in a career Gawande assumed had plateaued because plateaus feel like arrival.

Now consider the average professional: an engineer, an executive, a founder, a salesperson. Careers of thirty and forty years, compounding stakes, and, for the overwhelming majority, not one hour of skilled outside observation after the last classroom. We accept coaching as obvious for a golf swing and vaguely embarrassing for a career, which is exactly backwards, given which one pays the mortgage.

The resistance has a logic to it, and it is worth naming honestly. Coaching for performers is framed as sharpening; coaching for professionals is framed as remediation, something HR assigns after a bad review. There is also a self-assessment trap: most professionals believe they can see their own game. They cannot, and this is not an insult, it is a structural fact. You cannot watch your own swing. The habits doing the damage are precisely the ones that have become invisible to you, which is why Gawande's plateau was full of correctable errors he had stopped being able to see.

Having spent years on both sides of this, buying coaching and building coaching businesses, I can describe what good coaching actually does, because it is more mechanical than the mystique suggests. It supplies outside eyes on real performance, not self-reported performance: the actual interview, the actual sales call, the actual meeting, reviewed the way film gets reviewed. It supplies honest diagnosis, which friends and colleagues structurally cannot; their relationship with you depends on comfort, a coach's depends on your improvement. It converts vague ambition into deliberate practice, isolating the specific weak motion and drilling it, which almost nobody does for themselves because drilling weaknesses is unpleasant and life keeps offering the option of avoiding it. And it compresses feedback loops. A professional learns whether an approach works over months of scattered attempts. A coached professional finds out this week.

The economics follow directly. For anyone whose earnings hinge on performance in a small number of high-stakes moments, interviews, negotiations, sales conversations, funding pitches, even a modest improvement in those moments repriced across a career is one of the highest-return investments available. That is why high-ticket coaching exists and why serious people pay for it without apology. The fee is measured against a plateau, and the plateau is expensive.

The pattern across every field that takes performance seriously is identical and slightly humbling. The better someone is, the more coaching they consume. It is the middle of the distribution that goes it alone, protected by the belief that coaching is for people with problems. Woods rebuilt a swing that had just won by twelve. The rest of us can probably survive a second pair of eyes.

The first thing it teaches is that "Latin America" is not a market. It is a label covering twenty-plus jurisdictions with different currencies, different payment behavior, different regulatory postures, and commercial cultures that vary as much as Portugal varies from Poland. Strategies built for "LATAM" fail the way strategies built for "Europe" fail, except faster, because the operational differences bite earlier: how invoices actually get paid, how contracts actually get enforced, how hiring actually works. The companies that enter well pick one country, one segment, one motion, and earn the right to a second.

The second lesson is that distribution is the whole game, and distribution means partners, and partner selection is where most entries quietly die. The default failure mode is signing the first credible-seeming local partner, usually the one with the best English and the best conference presence, and discovering a year later that enthusiasm was the product. Partner diligence deserves the same rigor as an acquisition: reference the deals they claim, map their real relationships versus their stated ones, and structure the commercial terms so their economics only work if yours do. A market entry is not announced with a press release. It is announced with the first closed revenue, in-quarter, through a motion that can repeat.

Going the other direction, south to north, the problems invert. Latin American enterprises entering the US rarely have a product problem; the product survived a harder environment than the one it is entering. They have a translation problem, and I mean commercial translation, not language. Pricing built for LATAM procurement reads as suspiciously cheap to a US buyer. Selling motions built on relationship depth stall against process-driven procurement. Credibility that took a decade to build at home starts at zero, and the fix is not marketing. It is structure: reference customers chosen strategically, commercial terms that read as native, and early deals staffed to succeed conspicuously.

Both directions share one requirement that gets talked around: in-region accountability. Market entry run from headquarters, through quarterly flights and a local hire reporting into a distant VP, produces the entry theater everyone has seen, offices announced and quietly closed. Somebody senior has to own the outcome from inside the region, with authority over the partners and the motion, and be personally reachable when a deal wobbles at 9pm local. That is unglamorous and it is the difference. It is also, frankly, why I built the practice where I built it, rather than advising the Americas from a distance.

The opportunity in both lanes is real and, I would argue, mispriced. Capital and technology still see risk where operators on the ground see spread: talent, product maturity, and market gaps that pencil beautifully once someone can execute across the border with discipline. But the discipline is the price of admission. Diagnosis before entry, one market at a time, partners vetted like acquisitions, and one accountable person in the region.

The Americas reward companies that treat crossing borders as an operating problem. They punish everyone who treats it as an announcement.

I structured my practice as two-sided specifically to get out of that trap.

One side is the clients: founder-led companies at their ceiling, scale-ups whose operations turned into a mess, enterprises running on years of tech debt and duct-taped process. What they have in common is a problem that resists being solved from the inside, and a need for outside perspective with operational depth. What they get is diligence-grade thinking with a single point of accountability. They deal with me, and the outcome is on me.

The other side is the toolset: technology, process redesign, and a curated network of partners. SaaS and AI systems where they fit. Dev shops and implementation specialists where they don't. Senior independent operators, people with fifteen and twenty years of doing the actual work, staffed per engagement, sitting on my side of the table.

The two-sided structure matters because of what it removes. I carry no inventory. There is no platform I need the diagnosis to justify, no bench I need to keep billable, no partnership margin steering the recommendation. When the answer is a tool, we buy the right tool at the right price. When the answer is process and no tool at all, that is the prescription, and it has been more than once. The most honest sentence in advisory work is "you don't need to buy anything for this," and it is only sayable when your economics don't punish you for it.

The operator network is the other half of the argument. The standard agency model staffs engagements with whoever is available, wraps them in account management, and bills the client for the coordination overhead of managing its own people. I staff the other way around: the engagement defines the need, and the need selects specific senior people from a network built over years of seeing who actually delivers. No bloated agency. No vendor-management mode, where the client ends up supervising the help. The people who show up are people I would stake the outcome on, because contractually and reputationally, I am.

There is a version of this essay that sounds like every firm's "we're different" page, so let me make it falsifiable. The structure produces observable behaviors. Prescriptions that name what not to buy. Engagements that end on purpose, because the measure of the work is whether the team keeps it running after I am gone, and an advisor optimizing for extension would never write that sentence into the model. Commercial terms that lean toward success-aligned advisory, so the engagement only wins when the client does. A partner list that changes based on delivery, not margin.

Both sides of the table exist in every deal whether you name them or not. Someone is thinking about your problem, and someone is thinking about what they have to sell you. The whole design of this practice is to make those the same person, sitting on your side, with nothing in the truck.

I say this as a believer. MEDDPICC, Command of the Message, and Value Engineering are the best tools the profession has, and I have practiced them across more than a decade of enterprise work. But they are disciplines, and a discipline is different from a checklist in the same way playing scales is different from music. The checklist tells you what must be true by the end. The craft is how you get there without the prospect ever feeling processed.

The craft, as far as I can describe it, comes down to a few habits.

The first is that discovery is diagnosis, and diagnosis has a direction. An interrogation collects answers. A diagnosis tests hypotheses. Before any serious call I already have a theory of what is wrong, formed from everything observable from outside: the hiring pattern, the pricing page, the case studies they lead with, the shape of the org. The call is for pressure-testing that theory, and the difference shows immediately. "Tell me about your challenges" announces you did no work. "You've hired three enablement people in a year, which usually means the motion isn't transferring; where is it breaking?" announces you did, and earns a real answer.

The second is that the metrics you are hunting must be the prospect's, in the prospect's own words, at the prospect's own numbers. A business case built from my benchmarks is my homework; a business case built from their answers is their conclusion. I have built entire discovery instruments around this principle, structured so the conversation captures the prospect's numbers and plays them back against averages. When the diagnosis is assembled from things they said, there is nothing to argue with. You told me this. These are facts.

The third habit is comfort with silence and with bad news. Checklist discovery rushes past pain because pain is awkward; craft discovery sits in it, quantifies it, and is willing to conclude there is no fit. Some of the most valuable calls of my career ended with me saying the problem was real but I was the wrong prescription, and here is who to call. The methodology does not have a field for that. The craft insists on it, because a diagnosis you would bend for the sake of a deal is not a diagnosis, it is a script.

And the fourth is sequence. The methodologies are lists, but conversations are not; a paper champion is worthless identified in week one and priceless developed by week six, and pushing on economic buyer access before you have earned it burns the very champion you need to get there. Knowing what to establish is the checklist. Knowing when it can be established, and what has to be true first, is the craft, and it is learned the way all crafts are learned: by running hundreds of these, reviewing the ones that died, and noticing what the good ones had in common earlier than you wanted to admit.

Certify your team on the acronyms; the vocabulary matters, and a shared language for deal inspection is worth real money. Just remember what the acronym is for. The letters are the skeleton. The craft is everything that makes it walk.

A win rate is a ratio, and both halves are choices. A 20% rate on everything with a pulse and a 75% rate on rigorously qualified opportunities can be the same team, the same product, the same quarter. The difference is upstream discipline: what the team lets into the denominator. That is why my own bar for the practice is a win rate near the top of the range on qualified pursuits, not because closing is a magic trick, but because I refuse fights I have not diagnosed. A high rate, honestly constructed, is mostly a measure of what you decline.

Read as a diagnostic, win rate becomes useful the moment you decompose it by stage. Every leak has a signature. Losing heavily at the qualification-to-discovery joint means the top of funnel is generating conversations, not opportunities; the marketing message and the sales motion are describing two different buyers. Losing after technical evaluation means the product is being put in front of problems it does not solve, which is a discovery failure wearing an engineering costume. Losing at the very end, at contract or procurement, is the most misdiagnosed of all: teams call it a pricing problem or a legal problem, and it is almost always an early-stage problem, a champion never built, an economic buyer never met, paperwork surprising people it should never surprise. MEDDPICC exists precisely to make those absences visible early, when they cost a conversation instead of a quarter.

The same decomposition works in B2C, and I have used it there deliberately. With a coaching organization I worked with, we built the funnel review directly into the sales conversation: applications, screens, evaluations, offers, each stage with a benchmark rate, and the prospect's own numbers laid against it. The point was not theater. When someone sees exactly where their own funnel leaks, against averages rather than promises, the diagnosis is undeniable and the conversation changes character. It stops being persuasion and becomes joint problem-solving. People do not argue with their own numbers.

There are two failure modes to guard against. The first is gaming: a team that learns win rate is watched will quietly shrink the denominator, disqualifying late-stage losers retroactively so the ratio flatters. The cure is auditing entries, not exits. Review what got qualified and on what evidence, and the number stays honest. The second is worshiping the rate itself. A 95% win rate with a starving pipeline can mean world-class qualification, or it can mean a team so risk-averse it only pursues sure things and leaves the growth on the table. The rate never stands alone; it means something only next to coverage, cycle time, and average value.

Which is the general lesson underneath the specific one. Metrics in a revenue org are symptoms, and symptoms are gifts. A weird number is the system telling you where to look. The teams that improve fastest are not the ones with the prettiest dashboard. They are the ones that treat every ratio as a question, decompose it until the question is answerable, and then fix the stage where the truth turned out to live.

Celebrate the wins. Diagnose the rate.

The problem is that it ends quietly. There is no alarm. Revenue keeps growing, just slower, and the explanations sound reasonable: a soft quarter, a market thing, a hiring gap. But run the numbers on a founder-led company that has plateaued and you almost always find the same shape. The constraint is not demand and it is not the product. It is a calendar. One person's hours have become the throughput limit of the entire commercial engine, and everything else in the company has silently organized itself around that limit.

I worked with an organization that had been in business for twelve years, four people, selling a high-ticket service directly to individuals. Referrals and the founder's personal selling had carried it the entire way, and it had stopped. The instinct, and the stated problem, was leads. Get more at the top and growth resumes. But the diagnosis said otherwise. The funnel leaked at every joint below the top: calls that were booked but never confirmed, follow-ups that depended on memory, a CRM that was really a contact list, and, most fundamentally, a closing motion that existed only as the founder's instincts. Pouring leads into that system would have poured them onto the floor. Worse, it would have consumed more of the only truly scarce resource in the company, which was the founder's attention.

The ceiling, in other words, is rarely a volume problem. It is an externalization problem. Twelve years of judgment about who is a fit, what to ask, when to push, how to price, and what to promise were sitting inside one skull, applied brilliantly and invisibly, thirty times a month, capped there forever. The company did not need more of the founder. It needed the founder written down.

Externalizing a founder is delicate work, and half of it is emotional. The motion being extracted is the thing the founder is best at, often the thing the whole identity of the company was built on, and every step of turning it into a system feels like a small demotion. It is worth saying plainly: it is the opposite. A motion that dies with your calendar is a job. A motion your team runs to your standard is a company.

Mechanically, the work runs in a specific order, and the order matters because it has to fund itself. Fix the leaks closest to revenue first: pipeline stages with owners and exit criteria, confirmations and follow-ups that fire automatically, so the deals already in motion stop evaporating. Then turn discovery and closing into instruments, structured conversations that capture what the founder actually does, including the parts the founder does not know they do. Then, and only then, widen the top of funnel, because now the system underneath can carry the volume. Run it in reverse, leads first, and you scale the leak.

The measure of success is specific: the founder progressively out of the loop, deal by deal, until presence in the room is a choice rather than a requirement. The first deal that closes without the founder anywhere near it is worth more than the revenue on the contract. It is proof the ceiling was never the market.

Founder-led sales is a stage, not a strategy. The founders who scale past it are not the ones who worked more hours. They are the ones who noticed which asset the company actually ran on, and had the discipline to turn it into something that runs without them.

A prospectus is a strange document. It exists to sell shares, and it is legally required to tell the truth. Those two pressures, pulling against each other under liability, produce a discipline I have never seen matched anywhere else in business writing. You must explain, in plain declarative sentences, how the company actually makes money. Not the vision. The mechanism. Who pays, for what, how often, at what margin, through which channel, with what concentration. And then, in the section everyone reads last and should read first, you must disclose every material way it could break.

Writing risk factors for institutional investors is a forced honesty exercise. Vague worry is not allowed; each risk must be specific enough to be assessed. "Competition may increase" is filler. "Three customers represent 61% of revenue and each contract renews within the same fiscal quarter" is a risk factor. To write sentences like that you have to read the company inside and out: the contracts, the cohort data, the dependencies, the founder's calendar. The document is only as good as the examination behind it.

When I moved into enterprise technology, I noticed something uncomfortable. Discovery, as commonly practiced, would not survive prospectus standards. Ask a revenue leader how the company makes money and you get the pitch. Ask where it could break and you get either optimism or a competitor's name. The specific, mechanical, liability-grade description of the business rarely exists anywhere, including in the heads of the people running it. Decisions get made against the pitch instead of the mechanism, and the gap between the two is where quarters go to die.

So I brought the discipline with me, and it became the spine of how I diagnose. Before prescribing anything, I write the client's prospectus in miniature. How the money actually moves: which motions produce revenue, at what conversion, at what cost, on what timeline. And then the risk factors, drafted as if investors would read them: the pipeline concentrated in one segment nobody chose deliberately, the closing motion that exists only in the founder's instincts, the onboarding process that depends on four people's memory, the data layer where the numbers disagree depending on who exports them.

The exercise sounds heavy. It takes weeks, not hours, which is exactly why it earns its keep. Most bad prescriptions in this industry, the wrong software, the premature hire, the reorg that reorganizes the symptom, are downstream of a business description that was never written to a standard where anyone could be sued over it.

Here is a version any operator can run without me. Draft two pages. Page one: the mechanism, how a dollar of revenue is actually produced, stated so specifically that a stranger could audit it. Page two: ten risk factors, each concrete enough that you could design a test for it, ranked by how much of the year they could take with them. Then hand it to the two colleagues most likely to disagree and keep only the sentences that survive.

What survives is the truth you can build on. Everything else was the pitch. Investors learned long ago not to fund the pitch. Operators should stop running the company on it.

I say this as someone who spent more than a decade on the vendor side, closing and delivering large deals. The best work I did in those years always ran the same way: understand the operation deeply enough that the proposal read like a description of the client's own business, then fit technology to that description. The worst deals in the industry run in reverse. The vendor arrives with the prescription written, the discovery call is a formality to find quotes for the deck, and the software goes live against a problem nobody actually examined.

The failure is well documented. Industry surveys keep finding that the large majority of enterprise AI projects fail to reach production value, and the reasons cited are rarely the model or the code. They are the surrounding facts nobody diagnosed: data that turned out to be unstructured and disconnected, workflows that were never actually defined, costs that were never weighed against a measured baseline. Those are diagnosable conditions. They were simply never diagnosed, because diagnosis was not in anyone's commission plan.

Buyers are not innocent in this. Software is a comfortable purchase precisely because it substitutes for diagnosis. Choosing a platform feels like progress and requires no one to say anything uncomfortable about the org chart. If the real problem is that two executives have not agreed on what a qualified lead is, a new CRM postpones that conversation for eighteen months at a cost of several hundred thousand dollars. The invoice is easier than the meeting. I have watched companies buy the same category of tool three times in six years, each time configuring it faithfully around the same undiagnosed process, each time getting the same result with a newer interface.

The test I use is simple. A prescription is legitimate when it names the condition, and the condition has to be stated without reference to any product. "Deals stall because we have no shared definition of qualification, and reps improvise discovery" is a diagnosis. "We need better pipeline visibility" is a symptom wearing a vendor's vocabulary. If the problem statement only makes sense in the language of a product category, the category wrote it.

None of this is an argument against software. I build with software constantly; the automation work I am proudest of took a three-hour manual task down to minutes. But the sequence was diagnosis first: weeks mapping how the work actually ran, where the errors originated, and what a minute of latency cost, before a line of automation was written. The software worked because it was fitted to an examined condition. The same software, bought off a demo a year earlier, would have automated the wrong process faster.

So the discipline, for a buyer, comes down to a few questions asked in order. What is the problem, stated with no product nouns in the sentence? What is the evidence, and what did it cost us last quarter, measured, not felt? What would we expect to observe within ninety days if the problem were actually fixed? Only then: what is the smallest intervention, tool, process, person, or nothing, that produces that observation? Vendors who welcome those questions are worth your time. Vendors who route around them are telling you what their discovery was for.

Software is a prescription. Prescriptions are wonderful, on one condition that medicine figured out long ago and enterprise buying keeps forgetting. Examine first.

A solution is not the answer to a problem. A solution is a product looking for a question. Somebody's pet initiative, a vendor's platform, a reorg someone has wanted for years. Problems drift around looking for a decision to attach to. People wander in and out of meetings with limited attention. And when a choice opportunity opens, a budget cycle, a QBR, a crisis, whatever problems and solutions happen to be nearby get coupled and called a decision.

If that sounds like an insult to your company, sit in your own quarterly planning and take notes on what attaches to what. I have watched a data-warehouse project get approved as the answer to a churn problem because both were in the room the week the budget closed. Nobody was cynical. The streams just collided.

Revenue organizations in 2026 are nearly perfect garbage cans. The solution stream has never run faster: thousands of tools, each with a deck explaining which of your problems it answers. The participant stream churns; average tenure of a sales leader is barely two years, so the people who chose last year's solutions are gone before the results land. Problems, meanwhile, are genuinely ambiguous. Is the miss a pricing problem, a market problem, a talent problem, an enablement problem? Reasonable people disagree, which under garbage-can conditions means the loudest available solution wins.

Cohen, March, and Olsen were not writing a complaint. They were writing a description, and descriptions are useful because they tell you where the leverage is. You do not fix a garbage can by demanding people be more rational. You fix it by managing the streams and the structure of the cans.

In practice that means a few unfashionable things. Keep a written problem inventory that exists independently of any solution, reviewed on its own cadence, so problems have standing whether or not a vendor is in the building. Force every proposed solution to name, in writing, which inventory problem it claims to solve and what evidence would show it worked; solutions that cannot find a problem wait. Control the choice opportunities: fewer, better-prepared decision forums with the right participants locked in, because a decision made in a hallway is a collision, not a choice. And when I run diagnosis inside a client, the first artifact I build is exactly this map: which problems are real, which solutions are orphans, and which decisions were actually timing.

The deeper point of the 1972 paper is compassionate. Organizations are not stupid, and neither are the people in them. They are anarchies with limited attention operating under ambiguity, and their decision behavior follows from that structure. Once you accept it, "broken process" mostly dissolves. Most broken processes are decision problems in disguise: the process is fine, but problems, solutions, and forums are floating past each other and colliding at random. Name that honestly, bring discipline to the streams, and the process usually starts working on its own.

Fifty-plus years later, the garbage can is still the most accurate model of how companies choose that I have seen, and I have watched a lot of companies choose. The organizations that outperform are not the ones that eliminated the anarchy. They are the ones that noticed it, and built their decisions accordingly.

I learned this the slow way, across fourteen years of enterprise discovery calls. A travel platform once asked for capacity: more hands to work an onboarding queue that never emptied. Three hours of manual work per property, four to six months to ramp a new hire. The stated problem was throughput. The actual problem was that the entire process lived in people's heads. Every onboarding was an act of translation from tribal knowledge to keystrokes, which is why it was slow, why it produced errors, and why new hires took half a year to matter. Hiring against that problem would have made it worse. More people, more translation, more variance.

The gap between stated and actual problems is not a failure of honesty. It is a failure of vantage point. The person describing the problem is describing what it looks like from their seat, and their seat is inside the system that produced it. A VP of Sales sees deals dying in stage three and says "we have a closing problem." Sit in the pipeline reviews for two weeks and you find the deals were dead at qualification; stage three is just where the death certificate gets signed. The closing problem is a qualification problem wearing a costume.

There are reliable tells. When the same decision gets made three different ways depending on who is in the room, the problem is upstream of whatever anyone is describing. When a fix has been attempted twice and failed twice, the fix was aimed at a symptom. When the description of the problem includes a solution ("we need a new CRM"), someone has already skipped diagnosis, and the interesting question is what they skipped past.

The discipline that works is boring and slightly invasive. Read the deals that died, in the original, not the summary. Sit in the reviews and say nothing for the first three. Follow one unit of work, a deal, an onboarding, a ticket, through every handoff, and write down where it waits. Ask the people two levels down what they actually do when the documented process fails them, because it fails them daily and their workarounds are the truest map of the system you will find.

I hold a rule from my finance years, when the job was drafting prospectuses: you cannot describe a company to investors until you can explain how it makes money and where that could break, in writing, under liability. Discovery deserves the same standard. If I cannot write the problem statement in a way the client reads and says "that's uncomfortable and correct," I have not finished diagnosing, and anything I prescribe is a guess with an invoice attached.

The stated problem still matters. It tells you where it hurts, and pain is data. But treating the stated problem is how companies end up with a new CRM configured to automate a broken process, a hiring plan that scales a leak, or an AI tool bolted onto a workflow nobody can define. The most expensive sentence in business is "so we bought something for that."

Start with the assumption that the description is a symptom. Respect it, examine it, and then go find the disease. The clients who get the most from me are the ones willing to hear that the problem they budgeted for is not the one we are about to solve.