Clear
Known cause and effect. Configuration hygiene, standard properties, native integrations. We apply the checklist and move on. No workshop needed.
Most HubSpot projects fail on the diagnosis, not the build. We spend the first part of every engagement working out how much certainty the problem allows, then choose the method to match. This page explains how.
A go-to-market plan is a set of bets: that the forecast is roughly right, that the team will use the system, that the data underneath the dashboards is true, that the platform tier you bought fits the next two years. Each bet carries a cost when it is wrong, and most companies never price that cost because they never see it until the quarter closes.
We treat every HubSpot engagement as a way to lower the cost of being wrong: make the numbers defensible, make the process the path of least resistance, make the data verifiable, make the platform decisions reversible. That is the reason behind the audit-first method, the reversible change logs and the habit of saying “not yet” when a client wants to automate something the business has not stabilised.
We borrow Dave Snowden's Cynefin framework to decide how to act. The domain of the problem sets the method, and mislabelling the domain is how good teams build the wrong thing well. Five domains, including the one in the middle that most people skip.
Known cause and effect. Configuration hygiene, standard properties, native integrations. We apply the checklist and move on. No workshop needed.
Cause and effect exist but need expertise to see. Data models, pipeline design, migrations, integrations. This is where the audit and solution design earn their keep: analyse, then build.
Cause and effect only visible in hindsight. Adoption, new sales motions, pricing behaviour, cross-sell. We run safe-to-fail probes, watch the signals, and amplify what works instead of designing the end state up front.
Something is actively breaking: abandoned checkouts not captured, a workflow rewriting thousands of records. We act first to stabilise, then work out why, then move the problem to a calmer domain.
The centre. Confused is not knowing which domain you are in and acting anyway, usually with whatever worked last time. Aporetic is knowing that you do not yet know, and holding the question open long enough to find out. Every engagement starts here on purpose.
For the complex parts of an engagement we do not start from a target state. We map the constraints: what is fixed for now (a NetSuite contract, a sales team that prices by instinct, a HubSpot tier that will not change this year), what is expensive to move, and what is cheap to change tomorrow. Snowden's estuarine mapping gives this a shape: the things that shift slowly set the banks of the river, and the useful work happens in the water that still moves.
In practice this means we look for the smallest changes with the largest effect on the constraints themselves, we run several small probes rather than one big bet, and we treat the plan as something to be shaped as signals come back, not defended. Clients experience this as fewer surprises and a backlog that keeps making sense.
The baseline. HubSpot Academy's implementation, onboarding, data migration, data governance and reporting practices, encoded into the checklists and skills we run every audit and build against, so the routine parts are done the same way every time and the thinking goes where it is needed.
The structure. Bowtie stages, definitions, conversion and velocity metrics across marketing, sales and customer success, implemented as HubSpot objects, stages and reports. The framework at Winning by Design.
Situation, Pain, Impact, Critical Event, Decision. How we run discovery calls and how we teach sales teams to run theirs, so the CRM captures what matters instead of notes nobody reads.
Cynefin tells us which kind of problem we are in and therefore how to act. Estuarine mapping lays out the constraints and constructors on an energy and time grid, so we work on what can move rather than on abstract goals.
For tech-stack and build-versus-buy decisions: what in your stack is becoming a commodity, what is genuinely differentiating, and where custom code is a liability rather than an asset.
Before committing a scope we assume the project has already failed and work backwards to why. It surfaces the risks a normal review is too polite to name, and it changes the plan before the plan costs money.
Artefacts, Skills, Heuristics, Experience, Natural talent. Snowden's knowledge-mapping lens for the moment a client says “only Linda knows how that works”. It turns key-person dependency into something you can document, train and design around, which is most of what a HubSpot handover is.
Actants, Interactions, Monitors, Scaffolding: what you can actually manage in a complex system. We change interactions and scaffolding (routing, SLAs, stage gates), put monitors in place, and amplify or dampen what emerges instead of trying to change people directly.
Not a framework, a rule. Bulk changes are logged to a manifest before they run, records are re-read before every write, and deletions are proposals until you approve them. It is how we keep the cost of being wrong small.
Dave Snowden's body of work goes well beyond the four domains. These are the parts we use most in go-to-market and revenue operations work.
Two grids that separate what is known, knowable, unknown and unimaginable about a system from what the decision maker knows. Useful before a forecast is treated as a fact.
How novel practices become orthodoxy and then fade. It shapes our advice on when to adopt a HubSpot feature or an AI tool early, when to wait, and when to leave.
A typology for finding where change is possible: who can act, what the environment makes easy, and how the pieces are assembled. We use it to design pilots people can actually run.
Risk treated as part of designing actions rather than a review afterwards, with a human lens on how people behave under stress and ambiguity. The closest thing to a manifesto for how we scope engagements.
Read the live portal, interview the people, sort the problems into clear, complicated, complex and chaotic, and admit which ones are still unclear. Stabilise anything chaotic immediately.
Write down what cannot change, what is expensive, what is cheap. Run a pre-mortem on the proposed scope with the client in the room.
Configure the complicated parts with full documentation. Run small, reversible probes on the complex parts and measure them.
Monthly review of what the probes showed, what constraints moved, and what the backlog should become. Amplify, dampen, or stop.
It changes what we refuse to do. We will not automate a sales process the team has not agreed on, we will not enforce pricing rules a client changes weekly, and we will not build a target-state data model for a motion that is still being discovered. Each of those is a domain mismatch we have watched fail.
It removes the two most expensive weeks of most projects: the ones spent building the wrong thing. Diagnosis is part of the audit and design phases you would pay for anyway.
AI makes the complicated domain much faster: reading every workflow, recovering data, drafting documentation. It does not resolve complexity, and we do not pretend it does. Humans decide the probes and own every change to a customer record.
Thirty minutes is enough to sort what you are facing into the right domain and say what we would do first.
Discovery calls are free and go straight into the calendar.