ExpertsFMCompeting with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO)
In Depth · October 28, 2026
5 Selected Lessons:
reasoning_pattern · 2 case · 1 framework · 1 heuristic · 1
Token-bundle pricing: let users self-allocate ROI rather than price per outcome
Source
In Depth — Competing with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO) (October 28, 2026) · at 17:55 ▸
When this applies
when pricing a flexible platform whose value varies widely across heterogeneous use cases and outcome-based pricing is impractical
The takeaway
When a product's value is too heterogeneous to price per-outcome, price the underlying resource efficiently and let the customer allocate it to whichever use case yields them the best ROI.
Why it works
Outcome-based pricing requires enumerable, measurable outcomes; when outcomes are too numerous and varied, pricing efficient raw capacity (tokens) and letting users decide where to spend it preserves flexibility while still anchoring price to real inference cost plus margin.
One level up
Match pricing model granularity to the actual variance in how customers extract value; don't force a single pricing abstraction (seat, outcome) onto fundamentally diverse usage patterns.
Where it stops holding
This stops working when customers prefer predictability over flexibility and resist usage-based billing — which is why Town still offers seat-based plans as the entry point before usage-based add-ons.
Detail
procedure:
- Consider outcome-based pricing (admired via Brett Taylor/Sierra) but reject it if outcomes are too numerous/heterogeneous to price individually
- Price tokens near inference cost plus a platform fee
- Let users decide how to spend tokens based on their own ROI calculation
- Start customers on predictable seat-based pricing, then layer usage-based pricing on top once usage patterns are understood
- Build visibility tooling so businesses can see where ROI is high or low and adjust behavior
benchmarks: {"plans":"$10 to $99/month tiers observed in practice"}
rationale: Users wanted predictability first (seat pricing) then usage-based once they understood their own high-ROI use cases.
In their words
I have tokens that are super efficient. You buy a bundle of them as a user, and then you choose what's the right ROI of using those tokens for you.
Assume big incumbents will enter — plan positioning, not survival
Source
In Depth — Competing with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO) (October 28, 2026) · at 0:00 ▸
When this applies
when entering any market where the largest, best-funded players could plausibly enter once you prove the model works
The takeaway
Don't plan around avoiding competition from giants when you succeed — plan around how you'll win against them, because their entry is a near-certainty, not a risk.
Why it works
If success is visible and valuable, giants with existing distribution are structurally compelled to chase it, so the real strategic question isn't whether they'll come but how you differentiate once they do.
One level up
Treat obvious future competition as a known constraint to design around, not an uncertainty to hope away.
Where it stops holding
This stops working when the market is too small or low-margin to ever attract incumbent attention, making the giant-entry assumption irrelevant.
Detail
approach: Assume from day one that if the opportunity is real, the biggest incumbents will treat it as a top priority; shift focus from 'will they compete' to 'how do we win on product/marketing/emotional positioning'.
signals:
- market is large enough to be a 'top three priority' for giants
- your product threatens to become foundational infrastructure, not just an app
rationale: Knowing competition is inevitable lets you invest energy in defensible positioning instead of wasted hope that you'll be ignored.
In their words
I don't think there was ever a world for us where we were like, if it really starts working, is there any doubt that we'll be a top three priority at Microsoft, a top three priority at Google? Like, we knew we would be.
Startups can out-copy incumbents too — competition cuts both ways
Source
In Depth — Competing with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO) (October 28, 2026) · at 11:58 ▸
When this applies
when fast-copy dynamics threaten a startup's lead in any technology-driven market
The takeaway
Symmetric disruption of build-time means the same force that threatens you also opens previously 'safe' markets held by incumbents lacking real moats.
Why it works
If the pace of imitation has compressed for everyone, incumbents without true network effects are just as vulnerable to being leapfrogged by startups building ambitious things in 12 months that used to take 5 years.
One level up
When a structural shift lowers cost/time for everyone, reframe it from a threat to your position into an opportunity against others' positions.
Where it stops holding
This stops working when the incumbent actually possesses genuine network effects or structural moats that compressed build times don't erode.
Detail
approach: Reframe fast-copy risk by asking whether competitors also lack a durable moat (e.g., network effects) — if so, the same compression that threatens you also makes their markets contestable.
signals:
- competitor has distribution advantage but not network effects
- market previously assumed to take 5 years to build can now be built in ~12 months
rationale: Keeps founders from despairing about fast imitation by noting it symmetrically opens 'safe' incumbent markets to disruption.
In their words
And there are some of the big players out there that we're competing with. They also don't really have network effects. They may have distribution advantage, but it's not a network effect.
Multi-agent sharing policies only work where implicit trust already exists (SMB over enterprise)
Source
In Depth — Competing with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO) (October 28, 2026) · at 34:29 ▸ · at 37:20 ▸
When this applies
when a product requires an underlying trust fabric that large, heterogeneous organizations don't naturally possess
The takeaway
Match product rollout to the size/trust-density of the organization where the system's automated judgment calls will feel acceptable, not where the technology is theoretically capable.
Why it works
Human-in-the-loop approval doesn't scale as the number of agent-to-agent interactions grows, so the system must let AI decide sharing policies; but AI-decided sharing policies are only safe/acceptable where the human relationships already carry enough implicit trust (small teams), not in large, cross-team, cross-country orgs.
One level up
The limiting factor for autonomous systems acting on behalf of groups is often social trust density, not technical capability.
Where it stops holding
This stops working when even small teams contain sensitive sub-groups (e.g., HR, finance) where implicit trust doesn't actually extend across all members.
Detail
rule: Deploy autonomous cross-agent information sharing in small/mid organizations where implicit trust already exists, not large enterprises with low standardization and low inherent trust across departments.
threshold: contrast: '25 person SMB' willing to use it vs. 'Fortune 100' not ready; 'a thousand person company' cited as too large for an all-access team channel
rationale: Greze: a company like Google or Microsoft with enterprise customers 'can adapt to this future' poorly because 'none of their customers are ready to endorse this future.'
In their words
Mean, we have a strategy doc internally, and like one of the things that we have in the strategy is is we don't think a company like Google or Microsoft that has enterprise customers can adapt to this future because none of their customers are ready to endorse this future.
Town's fleeting clean-air advantage and the eroding product moat
Source
In Depth — Competing with OpenAI and Meta for your inbox | Jean-Denis Greze (Town Co-founder & CEO) (October 28, 2026) · at 11:58 ▸
When this applies
when enjoying a temporary lead after shipping a breakthrough feature in a fast-moving market
The takeaway
In fast-cycle markets, assume any single feature advantage decays within a quarter or two; durable advantage must come from compounding wins, not one feature.
Why it works
In AI-era product building, the time competitors need to dissect and replicate a winning feature has collapsed from years/decades to weeks/months because the underlying capability (model improvement) is broadly available and copying costs are low.
One level up
Moats built on product differentiation alone are temporary in any market where imitation cost has structurally dropped; look for mechanisms (network effects, trust, data ownership) that resist fast copying.
Where it stops holding
This stops working when imitation requires scarce resources competitors structurally lack (e.g., proprietary data, regulatory position), in which case the lead can last longer than weeks/months.
Detail
situation: Town launched in June and felt 'untouchable' for about two months with no visible competitors.
decision: Continued shipping fast (e.g., team/collaboration features) while recognizing the lead window was shrinking to one quarter, maybe two.
outcome: Competitors emerged 'next week' once a feature proved magical; the company concluded it must be right 'four or five times... over eighteen months' to truly win, since product differentiation alone is not a lasting moat.
lesson: Fast markets reward relentless, repeated execution rather than a single breakthrough feature, because any single win gets copied within months.
In their words
We launched in June, and I think all of June, all of July, we were like, oh, we're untouchable. Like, this thing is just, you know, totally untouchable. And then it's grown amazingly since then, but now there's clearly other people left and right that are in the race.