Approach

Know what kind of problem you have before you buy a solution for it.

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.

Book a discovery call See the services
5Cynefin domains, five different ways to act
6frameworks, each with one job
0irreversible bulk changes without a log
The premise

Revenue operations is risk management

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 cannot promise which bet will pay off. We can make each one better: sized so the downside is survivable, with the stop criteria agreed before the results come in, and judged on what was knowable at the time rather than on luck.

Sense-making first

Not every problem deserves a best practice

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.

Clear

Known cause and effect. Configuration hygiene, standard properties, native integrations. We apply HubSpot's best practice and move on. No workshop needed.

Complicated

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.

Complex

Cause and effect only visible in hindsight. Adoption, new sales motions, pricing behaviour, AI use cases. We run small, time-boxed pilots with stop criteria agreed up front, watch the signals, and scale what works instead of designing the end state first.

Chaotic

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.

Confused / Aporetic

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.

Constraints, not roadmaps

Mapping what can change, and what cannot

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. The things that shift slowly set the banks of the river. The useful work happens in the water that still moves.

In practice this means we look for the smallest changes with the largest effect, we run several small pilots rather than one big bet, and we treat the plan as something to be shaped as results come back, not defended. Clients experience this as fewer surprises and a backlog that keeps making sense.

The toolkit

Six frameworks, and the job each one does

HubSpot Academy's implementation, migration and governance practices are the baseline for everything we build, so the routine parts are done the same way every time. These six are where the thinking goes.

Cynefin

Dave Snowden's framework for telling which kind of problem you are in, and therefore how to act: follow the best practice, analyse, run small pilots, or stabilise first.

Wardley Maps

A method created by Simon Wardley to see how your customers' needs connect to the tools, data and teams that serve them, and how each part is changing. It shows where HubSpot or AI should do the work off the shelf and where your business is truly different and worth building for. We draw the map with your team, so the thinking stays with you.

ADKAR Change Management

Prosci's model: Awareness, Desire, Knowledge, Ability, Reinforcement. Most rollouts stall between knowing how the new system works and being able to use it on a busy day. We plan for that gap role by role, and stage the change so nobody is handed a plane on the day they learn to drive.

Faster, or Different?

Our test for every AI use case, built on Howard Yu's Two Boxes. Doing today's work faster saves money, but competitors get the same savings. Doing something you could not do before is where lasting advantage comes from. Both are worth doing. They need different scope, metrics and budget.

In an engagement

What this looks like week to week

  1. Diagnose the domain

    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.

    Week 1 to 2

  2. Map constraints and bets

    Write down what cannot change, what is expensive, what is cheap. Before we propose a scope, we stress-test it by assuming it failed and asking why, and we agree with you what would make us stop.

    Design phase

  3. Build the known, pilot the unknown

    Configure the complicated parts with full documentation. Run small, reversible pilots on the complex parts and measure them. Plan adoption for each role that will use the result.

    Build phase

  4. Shape as results return

    Monthly review of what the pilots showed, what constraints moved, how adoption is going and what the backlog should become. Scale, adjust, or stop.

    Run phase
Straight answers

Questions this approach raises

Is this consulting theory or does it change the work?

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.

Does sense-making slow the project down?

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.

How do you make sure the team actually uses what you build?

Adoption is planned, not hoped for. Each role gets the reason for the change, practice on their own records, and support after go-live. Where the jump is too big, we stage it: first the better car, then the plane. Usage is measured, and a workaround spreadsheet is treated as a finding, not a failure of the team.

Where does AI fit in this?

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 pilots and own every change to a customer record.

Bring us a problem, not a solution

Thirty minutes is enough to sort what you are facing into the right domain and say what we would do first.

  • 30 minutes, no slides
  • You leave with three concrete next steps
  • If we are not the right fit, we say so

Pick a time with Daniel

Discovery calls are free and go straight into the calendar.