You start simple. "Prospects" and "Customers." Two segments. Clean. Manageable.
Then someone asks: "Should we treat engaged customers differently than lapsed ones?" Sure, makes sense. Now you've got four segments.
Then: "What about high-value versus low-value?" Okay, eight segments.
Then product interests. Geographic nuances. Lifecycle stages. Channel preferences. Before you know it, you're maintaining 200+ segments, your campaign calendar looks like a Gantt chart from hell, and your creative team is drowning in requests for "just one more email variant for the West Coast high-value SUV owners who opened the last email but didn't click."
Sound familiar?
Here's what nobody tells you when you're starting out: Enterprise companies hit this wall at around 100,000 customers and spend millions trying to fix it. They hire consultancies. They buy new platforms. They reorganize their marketing ops teams. And they still can't escape the segment trap.
Startups have a chance to avoid this entirely—but only if you build differently from day one.
The alternative isn't "better segmentation." It's a fundamentally different mental model: state-based decisioning. And if you're a founder or early-stage operator, you have a narrow window to get this right before you scale into the same mess that's strangling enterprise marketing teams.
Let me explain what I mean.
What Segments Get Wrong (And Why You Inherited This Model Anyway)
Segmentation isn't stupid. It's just outdated.
Segments made perfect sense in the direct mail era. You literally had to physically sort mail into bins: "Prospects go here, customers go there, high-value customers in this special bin." Digital marketing inherited this mental model without questioning whether it still made sense. And every major marketing platform—Salesforce, Adobe, HubSpot, Braze—was architected around it.
So when you're setting up your first marketing automation system, segments feel like "the way." The platform UI nudges you toward them. Your agency recommends them. That's just how it's done.
But here's the problem: the constraints that made segments necessary are gone. You're not sorting physical mail anymore. You're not limited by batch processing. You have real-time data, event streams, and the ability to make decisions in the moment.
Yet we're still using a framework designed for 1990s logistics.
What Segments Actually Are
Let's be clear about what we're dealing with:
- Static buckets based on attributes or behaviors
- Require constant maintenance as you add dimensions
- Force you to choose when someone fits multiple segments (the dreaded "primary segment" problem)
- Scale poorly through combinatorial explosion
- Miss the context of where someone is right now
Quick terminology note: When I say "state-based decisioning," I mean decisioning based on relationship states—like "at risk" or "service due." I'm not talking about geographic states, though honestly, "lives in Chicago in February" probably should trigger warm-weather vacation offers.
Here's a real example from my world in automotive marketing:
Someone bought a car two years ago. In a segment-based system, they land in: "Customer - 2 Year Owner - Midwest - SUV."
Okay, great. Now what?
Are they:
- Happy and just need a routine service reminder?
- Unhappy and showing churn risk?
- Starting to research their next vehicle?
- Completely satisfied and prefer minimal contact?
The segment tells you almost nothing about what to do next.
The Yearbook Photo Problem
Here's how I think about it: Segments are like yearbook photos. They capture who someone was at a moment in time. Useful for recognition, terrible for action.
States are like your Ring doorbell. They show who's at your door right now and what they need.
When someone rings your doorbell at 11pm, you don't pull out their yearbook photo. You look at the camera and respond to their current situation.
That's the difference.
The N-Squared Problem
The other issue with segments: they multiply in ways that get out of control fast.
- 5 segments = manageable
- 10 segments = 100 possible combinations to think about
- 20 segments = 400 combinations
- 50 segments = you're drowning
You know you've hit peak segment complexity when you need a Venn diagram with 17 circles just to figure out which email someone should receive. At that point you're not doing marketing—you're doing set theory homework.
State-Based Decisioning: The Alternative Mental Model
Okay, so segments have problems. What's the alternative?
Here's the core idea: Segments are like a census—they tell you who's out there. States are like traffic lights—they tell you what's happening RIGHT NOW and what you should do about it.
You wouldn't navigate Chicago using census data from 2020. You'd check the traffic. But most marketing systems are still trying to drive using demographic snapshots instead of real-time signals.
What Is a "State"?
A state describes where someone is in their relationship with you right now. Not their demographics. Not their historical behavior category. Their current context.
Key characteristics:
- Contextual, not demographic
- Can overlap (someone can be "Service Due" AND "At Risk" simultaneously)
- Have priority hierarchies (red light beats yellow beats green)
- Designed around decision-making, not reporting
Let me show you the difference with a side-by-side comparison.
Segments vs. States: An Automotive Example
SEGMENTS APPROACH:
- Prospect - Shopper
- Prospect - In-Market
- Customer - New (0-6 months)
- Customer - Established (6-24 months)
- Customer - Loyal (24+ months)
- Customer - Service Due
- Customer - At Risk
And this is the simple version. In reality, you'd multiply these by product type (sedan, SUV, truck), geography (regional offers), value tier (economy, premium, luxury), channel preference (email, SMS, app)...
You see where this goes.
STATES APPROACH:
- Exploration (researching, not ready to buy)
- Evaluation (comparing options, high intent)
- Transaction (in active purchase process)
- Onboarding (first 90 days of ownership)
- Engaged Owner (active, satisfied)
- Service Need (routine maintenance due)
- Concern (expressed problem or complaint)
- Risk (showing defection signals)
- Advocacy (referring others, promoting brand)
Notice What's Different
These states describe the relationship condition, not the customer profile. They're fewer in number but contextually richer. They can overlap. And they're explicitly designed around the question: "What should we do next?"
Let me walk through an example using the traffic light metaphor:
Someone bought a car two years ago.
The segment view: "Customer - 2 Year Owner - Midwest - SUV"
That's demographic data. It's like knowing their address and what's in their driveway.
The state view might show:
- Service Due (yellow light - proactive reminder needed)
- Recent Complaint (red light - retention risk)
- High Engagement (green light - advocacy opportunity)
Now you know what to do. The red light beats the yellow light beats the green light. Address the complaint first, then offer service scheduling, then (maybe) ask for a referral.
You're making contextual decisions, not executing pre-planned campaigns.
Priority Hierarchies Are Critical
Just like traffic signals have rules (red always overrides green), states need priority logic:
- Concern/Issue states override everything (don't upsell someone who just filed a complaint)
- Transaction states beat routine communication (don't interrupt a purchase flow with a survey)
- Advocacy opportunities come after needs are met (earn the right to ask for referrals)
This isn't arbitrary—it's customer-centric design baked into your architecture.
Why This Matters for AI (And Why I Keep Hammering on This)
This is where state-based thinking transforms from "interesting architecture idea" to "competitive advantage."
If you've read my other posts, you know I'm all about predictive AI as the workhorse while everyone else chases generative AI demos. State-based decisioning is how you actually put that predictive power to work.
Predictive AI Works Better With States
Compare these two questions:
Segment-based: "Predict who will click this email campaign"
State-based: "Predict who is transitioning from Engaged Owner to At Risk"
One optimizes a campaign. The other prevents churn. Different game entirely.
Why does this matter?
- ML models are predicting transitions, not just responses
- You're asking about relationship dynamics, not campaign performance
- The predictions are more actionable (you can intervene on state changes)
- You're building toward customer lifetime value, not just next conversion
Content Personalization Becomes Contextual
With segments, you end up building 47 email variants for different segment combinations. Your creative team drowns. Testing becomes impossible because you've got too many variants and not enough volume in each.
With states, you build modular content blocks that assemble based on current state. Einstein Personalization (or equivalent) picks the right module. Way less creative burden. Way more relevant to the recipient.
Remember my post about moving from "If/Then" to intelligent predictions? State-based architecture is how you actually enable that. You're not writing brittle rules for every segment combination—you're letting the AI pick content based on current context.
Orchestration Becomes Smarter
Segments force calendar-based campaigns:
- "Run Q2 reactivation campaign to lapsed segment"
- Everyone gets it on the same day regardless of their situation
States enable trigger-based orchestration:
- "When someone enters 'Risk' state, initiate retention sequence"
- "When someone is in both 'Service Due' and 'Engaged Owner,' send convenience-focused reminder"
Your email templates get simpler because decisioning happens in the data layer, not the template layer. Less AMPscript spaghetti. More maintainable. Less brittle.
It's like moving from a spreadsheet full of nested IF statements to a proper database with views. Same information, way better structure.
Why Enterprises Can't (Or Won't) Build This
Now here's the painful part: if state-based decisioning is so much better, why isn't everyone doing it?
The reason isn't technical. It's political.
The IT Problem
Legacy architecture is the first barrier. Existing marketing systems—Salesforce Marketing Cloud, Adobe Campaign, all the major platforms—are architected around segments and campaigns. The data models, the UI, the reporting, everything assumes this structure.
Rebuilding that is a massive replatforming project. And in enterprise IT, "massive replatforming project" translates to "career-threatening risk."
Nobody wants to own it:
- IT doesn't want to own a marketing data model redesign
- Marketing doesn't have the technical chops to spec it properly
- The data team is already underwater with other requests
- It falls between org silos, so it goes nowhere
The result: "Why would we tear down what's working?" (Even if "working" means "barely functional and getting worse every quarter.")
In enterprise, suggesting a fundamental architecture change is like suggesting your extended family switch Thanksgiving to a different house. Technically possible. Logically sound. Never going to happen.
The Agency ATM (This Is the Part Nobody Talks About)
But here's the really inconvenient truth: Your agency has zero incentive to recommend this.
Their business model depends on complexity and volume.
Think about what they bill for:
- Creative concepting for each segment variation
- Copywriting for 47 different email versions
- Design and production for all those assets
- Campaign deployment and QA
- Performance reporting on all those segments
- "Strategic segmentation workshops" (annual revenue stream)
State-based decisioning with modular content? That could reduce their ongoing creative requests by 60%+. That's 60% less revenue.
So what do they recommend instead?
- More personas (more concepting workshops)
- More segmentation refinement (more strategy retainers)
- More journey mapping (more billable discovery)
- More campaign "innovation" (more production work)
- More creative testing (more variants to build)
All of which keeps the ATM humming.
Your agency's strategic recommendation always sounds sophisticated: "We should develop micro-segments based on psychographic clustering and propensity modeling."
Translation: "We'd like to bill you for six more months of creative production."
Look, agencies aren't evil. They're rational economic actors. But expecting them to recommend an architecture that kills their most profitable revenue stream is like expecting a lawyer to recommend you stop getting divorced. Technically good advice. Bad for business.
The Frozen Middle
Meanwhile, inside the enterprise:
- Marketing leadership doesn't understand the technical difference
- Operations teams are too busy keeping the current system running
- Nobody has bandwidth for "innovation projects"
- Career risk looms: if you push this and it fails, you own it
- Easier to complain about complexity than fix the foundation
A weird alliance emerges:
- Agencies don't want it (kills revenue)
- IT doesn't want it (too hard, too risky)
- Creative teams might not want it (less variety, less visibility)
- Executives don't understand it, so they fund what agencies recommend
The only people who actually want state-based decisioning:
- Operations people drowning in campaign management
- Lifecycle marketers frustrated by context-blind communications
- Data people who see the scalability cliff coming
- Customers getting the wrong messages at the wrong times (but they don't get a vote)
So you've got IT saying "too hard," agencies saying "not necessary," and executives hearing "we need more sophisticated segmentation."
Meanwhile, operations is drowning, customers are getting service reminders mixed with conquest offers, and nobody's measuring the cost of this complexity.
Enterprises are trapped. They know segmentation is breaking. But the organizational antibodies prevent the cure.
The Startup Advantage (And How to Actually Use It)
But if you're a startup? You don't have these antibodies yet.
Here's your unfair advantage: You get to build this right the first time.
Your Structural Advantages
1. No Legacy Architecture
You're choosing a marketing platform now. You can design for states from the beginning. No migration pain. No political battles to refactor existing systems. Clean slate is worth more than you think.
2. No Agency Dependency
You're building lean, modular content anyway—you have to, because you don't have budget for 47 variants. Your constraints force better architecture. Efficiency isn't a threat to your business model. It is your business model.
3. Smaller Data Sets (For Now)
It's way easier to model states with 10,000 customers than 10 million. You can test fast. Iterate quickly. Mistakes are recoverable. You can even talk directly to customers to validate your state definitions (try doing that at Ford).
4. Direct Control
No IT approval process. No change management theater. No cross-functional alignment meetings with 17 stakeholders. You decide. You build. You ship.
You have a chance to install the traffic light system from the beginning. Enterprises are stuck trying to retrofit traffic lights into a census database while keeping 10 lanes of traffic moving.
It's way easier to install the lights before you pave the roads.
How to Actually Do This
Okay, enough theory. Here's the practical playbook.
Step 1: Start With State Definitions, Not Segments
Map the actual relationship states in your business. Keep it simple—5 to 8 states max to start. Focus on the decision-making question: "If someone is in THIS state, what should we do differently?"
Define priority hierarchies: which states override others when someone is in multiple states simultaneously.
Document state transition triggers clearly.
Example for a SaaS product:
- Trial (first 14 days, exploring product)
- Activated (completed key onboarding action)
- Engaged (regular usage pattern established)
- Stalled (no usage in past 7 days)
- At Risk (usage declining, or unresolved support issue)
- Expansion Opportunity (hitting plan limits, or using advanced features)
- Churned (cancelled subscription)
For each state, ask: What should our communication or action be?
Step 2: Choose Tools That Support This
Most modern platforms can be architected this way—Customer.io, Iterable, Braze, even parts of HubSpot. But their UX often nudges you toward segments because that's the inherited mental model.
Look for:
- Event-driven capabilities (not just batch/campaign execution)
- API-first architecture (so you can build custom logic outside the platform UI)
- Flexible data models (not rigid segment hierarchies)
Warning: You'll have to be intentional. The platform will want you to build segments. Resist.
Step 3: Build Modular Content From Day One
Think content blocks that assemble, not campaign-specific creative assets.
- Header + Body + CTA, where each component can vary independently
- Design system that supports this componentization
- Make it easy to test and iterate on individual components
Resist the temptation to build custom campaigns for every scenario. Build the Lego blocks first. Assemble them based on state.
Step 4: Instrument State Transitions
Track when people enter and exit states as explicit events in your data layer.
Measure state progression: Are people moving toward Engaged? Toward Expansion Opportunity? Toward Advocacy?
Optimize for state health, not campaign metrics.
"What percentage of Trial users reach Activated within 3 days?" is way more useful than "What percentage clicked the email?"
Step 5: Keep It Simple
Don't over-engineer. Ship and learn. Add complexity only when the data shows you need it.
You're building a foundation, not a finished cathedral.
Startups have a huge advantage here: nobody's built a segmentation machine yet that needs to be taken out back and shot. You can just... not build the wrong thing.
The Competitive Moat This Creates
Here's what you get if you do this right:
When you scale, you scale cleanly. Going from 10,000 customers to 100,000 doesn't break your system. You're adding complexity linearly, not exponentially. Your operational costs stay manageable. You don't hit the wall enterprises hit.
Your customer experience is better. Contextually relevant communications. You're not sending service reminders to someone who just filed a complaint. Less noise, more signal. Better engagement. Better retention.
You're positioned for AI leverage. When you're ready to add predictive models, you already have clean state-based data. State transitions are perfect training data for ML. You're building toward sophistication, not trying to escape chaos.
You look professional to enterprise buyers. If you're building MarTech SaaS, this architecture signals maturity. Enterprise buyers recognize state-based thinking—even if they can't build it themselves. "We support state-based decisioning workflows" becomes a genuine competitive differentiator.
Meanwhile, your enterprise competitors are stuck in segment hell, paying agencies millions to manage the complexity, fighting IT battles to modernize legacy systems, and drowning in ad hoc campaign requests because everything's too brittle to automate.
The Boring Work That Wins
State-based decisioning isn't sexy.
It won't get you on stage at SaaStr. Your creative team won't put it in their portfolio. There's no viral LinkedIn post about your innovative segmentation methodology. No case study with impressive-sounding frameworks and acronyms.
What it is: infrastructure.
It's the plumbing of customer engagement. The foundation that lets everything else work. The boring work that compounds over time.
If you've read my other posts, you know I think about this stuff through a Chicago lens. Predictive AI is the "Chicago of AI"—not flashy like Hollywood, but doing the heavy lifting that makes everything else possible. State-based architecture is the same energy.
It's not Hollywood-flashy. It's big shoulders. It's the work that makes everything else work.
The companies that will dominate the next decade of marketing aren't the ones with the flashiest creative or the most sophisticated segmentation taxonomies. They're the ones who built the right foundation early—and didn't have to rebuild it later.
You have a window to be one of those companies.
Don't waste it building the same broken architecture that enterprises are desperately trying to escape.
Segments gave us maps. States give us GPS.
Both show you where customers are—but only one helps you decide what to do about it in real-time.
And just like with GPS: once you've used it, you'd never go back to paper maps.
What are you building? I'd love to hear how you're thinking about customer decisioning architecture. Comment below or you can find me on LinkedIn or at mikehotz.com.




