Panos Sisamos

Panos SisamosJun 18, 2026

You had one outbound campaign this year that actually worked. ⠀ Ask "why" to whoever ran it, and watch them guess. ⠀ It worked because a few things lined up at once: the list, the timing, the angle. Move all three in one send and the reply rate can't tell you which one mattered. Nothing was held still, so nothing is attributable. ⠀ An experiment needs a slice: a piece of the market narrow enough that only one thing is in play. ⠀ So you microsegment. Cut the market into cells small enough to carry a single hypothesis: `payments fintech · 200-500 · RevOps lead`, just off a CRM migration. One who, one thing that just happened, one angle. Then you name the slice, so the result joins back to it and the next send builds on this one. ⠀ Then you give the slice a real sample size. In our sends, cold reply rates run 2 to 3 percent, so a small batch is just variance. Rough arithmetic: 100 to 200 sends per slice is enough to tighten or kill a hypothesis; proving a 1-point lift on that base takes 3,000 to 4,500. ⠀ The finer you slice, the cleaner the experiment and the harder it is to power. A 50-name microsegment can't be an experiment. So you slice as fine as your volume allows, and you label what's directional and what's decided. ⠀ Name every slice. Enough labeled sends, and the map draws itself: which segments to scale, which to drop. ⠀ // ⠀ 🤖 AI-assisted, grounded in real work from our repo + public sources. The goal: close the gap until you can't tell, while sharing what we build at Relevance. Tell us what's off, it trains the agents. ⠀ sources → internal: outbound-as-experiment (positioning pillar #4); the microsegmentation + named-cell + sample-size discipline (Hermes experimentation evidence docs). → external: Lemlist and Outreach cold-email A/B sample-size guidance (100 to 200 per variant for a directional read). The per-arm "few thousand" figure is our own approximate power calc (two-sided alpha 0.05, 80% power), not a vendor number.

Panos SisamosJun 17, 2026

We're going full circle, and I'm getting a bit dizzy. If you asked me 2 years ago, I'd say start with a service to solve the problem, shift into a product if it's scalable enough. If you ask me now, I'd say start with a service to solve the problem, augment the shit out of it with AI agents to streamline delivery and make $$. Sell the outcome, just streamline the delivery. But I'm seeing more and more tools offering service on top, and with an established distribution, it's a revenue line more impactful than the actual product. One thing is certain: Services-as-software is the real AI shift, and it's bigger than GTM. Sequoia calls it a 10x-the-cloud. ⠀ A service still sells an outcome: ☑︎ pipeline, ☑︎ a legal brief, ☑︎ a finished design. What changes is who does each step. 🤖 The high-volume, repeatable work moves to agents. 💁‍♂️ Humans stay where taste, judgement and relationships decide the result. ⠀ _ Our translation, for GTM: ⠀ The old shape, a managed service: humans deliver every step. 💁‍♂️ Setup, 💁‍♂️ strategy, 💁‍♂️ inputs, 💁‍♂️ execution, 💁‍♂️ judgement, 💁‍♂️ delivery, 💁‍♂️ client comms, 💁‍♂️ the loop. It works, but it scales with headcount, and the context that makes it work lives in one person's head. ⠀ The new shape, an AI-managed service: agents run the heavy lifting. 💁‍♂️ Setup, 💁‍♂️ strategy, 🤖 inputs 🤖 execution, 💁‍♂️ judgement, 🤖 delivery, 💁‍♂️ client comms, 🤖 the loop. Humans stay on the four steps that need them: setup, strategy, judgement, client comms. Same deliverable, except the context lives in a graph instead of a head, so nothing resets. ⠀ Keep the judgement, automate the hours, and the service scales like software. That's what makes it bigger than cloud. Full piece published on: https://lnkd.in/ei3QAPPD If you wanna watch this unravel in real time, follow Relevance. to stay in the loop. ⠀ // ⠀ 🤖 AI-assisted, grounded in real work from our repo + public sources. The goal: close the gap until you can't tell, while sharing what we build at Relevance. Tell us what's off, it trains the agents. ⠀ sources → internal: our AI-managed-service delivery model (the eight stages; humans on setup, strategy, judgement, client comms; the context graph that replaces institutional amnesia). → external: Sequoia, services-as-software is "10× the cloud opportunity" (AI Ascent 2025).

Panos SisamosJun 16, 2026

We send around 100,000 emails a month. We also run campaigns into a few hundred accounts at a time. Two outbound games, opposite constraints. // 𝗧𝗵𝗲 𝘃𝗲𝗿𝘁𝗶𝗰𝗮𝗹 𝗴𝗮𝗺𝗲 The vertical game is low-volume and high-context. A few hundred accounts, real signals, timing, a message written for one situation. There, intent data earns its keep. // 𝗧𝗵𝗲 𝗵𝗼𝗿𝗶𝘇𝗼𝗻𝘁𝗮𝗹 𝗴𝗮𝗺𝗲 The horizontal game is high-volume and broad. Wide coverage across a large TAM, the math working at the cohort level. At that volume, buying signals barely move the number. The binding constraint is whether the data underneath is good, broad, and fresh. _ Here's why that dominates everything else at scale. Send 100k a month against a list that's 5% bad and that's 5,000 bounces a month, quietly burning the domain reputation that carries your good sends too. Coverage gaps are worse: a contact that isn't in the database is a slice of your TAM you can't reach, and no signal model invents a person who isn't there. And lists rot. People change jobs every month, so anything more than a few weeks old is decaying in absolute numbers you feel at this volume. So at scale the whole thing collapses to one question: Can you get broad, verified, fresh coverage, cheaply, at the volume you actually send? That's the exact shape of what prospeo.io does well. ✅ The best coverage I've found,  ✅ triple-verified emails,  ✅ a database that refreshes on a 7-day cycle,  ✅ and cheap enough to run at real volume. Signals win the precision game.  Coverage wins the volume game. We run both, and the data layer decides whether either one works. Prospeo.io is what we run for the data. Point it at whatever source you use now and compare.