wiki › Activation

"Don't dabble"

"Don't dabble" is the discipline that when a team sets out to make a product work better for the people using it, it does the work at the depth that actually moves the user's experience rather than stopping at the surface. Dabbling is the shortcut version: tweaking some copy, swapping a testimonial, renaming a plan tier, then treating the job as done while the thing users are trying to accomplish is no easier than it was before. The honest test is whether the work measurably improved how well the product serves its users, or only made it look more responsive to them.

Definition

When investing in path work for a route, the discipline is to do the work at the depth the route's efficacy requires — not to perform the operational motions at a surface level and call the path built.

Path-flavored object work

Dabbling is the failure mode the discipline names. The team has adopted path vocabulary but is applying it as if to an object — the offering as the unit being polished — rather than as if to a path, the user's route as the unit being improved. The vocabulary changed; the unit of work didn't. From outside, the work looks like serious path work: an intent-detection question goes in, users get tagged by intent, copy varies by segment. Inside, the underlying route — the actual sequence of states and affordances the user moves through — is the same one everyone gets.

The substantive commitment is that path work makes the offering serve users pursuing the intent more effectively than alternatives would. A path that produces no measurable improvement in route efficacy is a path in name only.

Three forms dabbling takes

  • Stuck at lightweight depth: intent-mirroring moves produced signal that warranted deepening, but the team never advanced to deeper differentiation. The principle in path investment is start cheap, deepen on evidence — not stay cheap forever. Cheap moves continued past the evidence bar are dabbling, not baby-pokemon discipline.
  • Differentiation without performance gain: paths exist in the codebase but don't measurably outperform OSFA. The artifact got built; the route didn't get better.
  • Performance theater: visible intent-acknowledgment — intent-named tier plans, intent-tagged emails, persona-routed onboarding screens — without the substantive route-redesign that would make the path work better for the named intent.

The depth Supply requires

The four-filter test names Supply as requiring sustained over-time investment, not moment-in-time capacity. The competitive position on a transition is produced and maintained by depth that accumulates; nominal four-filter passage doesn't substitute for it. Dabbling is the failure mode where teams clear the filters on paper but don't sustain the depth Supply actually demands. The provider-preference questions inside Supply — do we want to help these users, do we like the recurring details of the work, do we believe the work makes the world better — exist partly because they predict whether a team will sustain that depth, and dabbling tends to surface when those commitments are weak.

Example

A team detects two first-session intents at signup — "setting up for my team" versus "evaluating for myself" — and treats this as the basis for a differentiated path. They rename their tier plans to reflect the split, vary the welcome-email subject line by intent, and tag the segments in analytics. The signup flow, dashboard defaults, and activation sequence stay identical across both segments. Conversion to first paid conversion doesn't move. The team built a path in vocabulary and treated it as built; the route the user traverses to value never changed.

See also