Why Sense-Making Frameworks Belong in Your Go-to-Market Strategy
5 September 2026 · Daniel Secareanu

Most go-to-market projects do not fail on execution. They fail earlier, on the diagnosis: a team treats a complex problem as if it were merely complicated, buys a best practice for it, and then wonders why the CRM, the playbook or the AI pilot never took. This article explains the frameworks we use at RevTech Agency to avoid that mistake, most of them from Dave Snowden's Cynefin ecosystem, and why they matter for anyone running revenue.
Start with the kind of problem, not the solution
The Cynefin framework sorts situations into domains that call for different kinds of action. In clear situations cause and effect are obvious and a checklist is the right tool: property naming standards, native integrations, tracking code. In complicated ones cause and effect exist but need expertise to see, so you analyse and then build: a data model, a migration, a pipeline design. In complex situations cause and effect are only visible in hindsight. Adoption of a new sales process, a new pricing motion, cross-sell behaviour: nobody can specify the end state in advance, so you run safe-to-fail probes, watch what happens and amplify what works. And in chaotic situations something is actively breaking and you stabilise first, then ask why. The fifth domain sits in the middle: confused when you do not know which domain you are in and act anyway, aporetic when you know that you do not yet know and deliberately hold the question open. Good engagements start there.
The go-to-market relevance is blunt. A forecast is a complicated problem you can engineer. Whether reps will follow the stages behind that forecast is a complex one you cannot. Most CRM projects treat both the same way, and that is where the budget goes.
Map constraints, not roadmaps
For the complex parts we do not draw a target state. Estuarine mapping puts the constraints and constructors of a situation on a grid of energy cost against time to change. Some things are granite: an ERP contract, a compensation plan, a HubSpot tier that will not change this year. Some are sandbanks that shift daily. The useful work happens in the water that still moves, in many small, monitored changes rather than one large bet. Clients experience this as fewer surprises and a backlog that keeps making sense as signals come back.
Know what you do not know
Snowden's uncertainty matrices separate what is known, knowable, unknown or unimaginable about a system from what the decision maker actually knows. It is a humbling exercise to run on a pipeline report. Half of what leadership treats as known is at best knowable, and some of it, such as how a new segment will buy, is not knowable yet at all. Naming that changes how much weight a plan can carry.
Timing adoption
Flexuous curves describe how a novel practice gains traction, becomes orthodoxy and then fades as its limits show. In revenue technology this cycle is fast. It informs our advice on when to adopt a HubSpot feature or an AI tool early, when to wait for the second version, and when to leave a tool the market has already moved past.
Find where change is possible
The 3As, agency, affordance and assemblage, ask who can act, what the environment makes easy, and how the pieces are assembled. Instead of asking a sales team to adopt a new mindset, we change what is easy: the default view, the required field, the routing rule. Emergent behaviour cannot be engineered directly, but the constraints around it can.
Replace key-person dependency with knowledge you can manage
ASHEN stands for artefacts, skills, heuristics, experience and natural talent. It is Snowden's tool for the moment someone says “only Linda knows how that works”. Rewriting that sentence as “this requires these artefacts, these skills and these heuristics, and right now only Linda has them” turns a risk into a plan. Almost every HubSpot handover we do is an ASHEN exercise in disguise.
Manage what can actually be managed
AIMS, actants, interactions, monitors and scaffolding, is the honest answer to what you can manage in a complex system. Not people's attitudes. You can change interactions, put scaffolding in place (routing, SLAs, stage gates, definitions) and install monitors that show early signs of emergence, then amplify or dampen. That is a precise description of good RevOps.
Treat risk as part of the design
WRASSE, Weaving Risk and Strategy, moves risk from a review after the plan to a property of the actions themselves, and adds a human lens on how people behave under stress and ambiguity. It matches our own premise: every go-to-market decision is a bet, and the job is to lower the cost of being wrong. Reversible changes, small probes, pre-mortems before scope is committed and documentation written for the client's team are all ways of doing that.
Why this matters for your revenue operation
- You stop buying best practices for complex problems. Adoption, pricing behaviour and new motions get probes and monitors, not a twelve-week build plan.
- You spend expertise where it works. Data models, migrations and integrations are complicated and deserve rigorous analysis and documentation.
- You know how much your forecast can carry. The uncertainty matrices make the difference between known and knowable explicit before anyone hires against a number.
- You reduce the cost of being wrong. Reversible changes, small bets and early monitors mean failure is information, not a write-off.
None of this is theory we bolt onto proposals. It changes what we refuse to build, what we build first, and how we measure whether it worked. If you want to see how it applies to your own portal, book a discovery call or read the longer version on our Approach page.
Founder of RevTech Agency, RevOps Solution Architect and HubSpot Platinum Partner. 25+ years in marketing and technology, 10+ on HubSpot, 5+ in revenue operations.