Tessa Kriesel - the DevTools sprint
Tessa Kriesel used to pitch a four-week DevRel program. It wasn't landing. She compressed the exact same work into a single day, pitched it again, and suddenly everyone said yes — not because the work changed, but because a day is something you can actually block out on a calendar.
Tessa Kriesel is the founder of Built for Devs, where she runs one-day go-to-market sprints for developer tools, drawing on previous senior DevRel roles at Snap and Twitter. The sprint compresses weeks of strategy work — customer research, positioning, channel selection — into a single focused day.
We get into why 'problem fit' has to be the foundation everything else sits on, how she uses a developer-experience audit — literally watching a real developer try to use the product on camera — to find out what founders can't see because they're too close to their own tool, and the very concrete signal for knowing you haven't talked to enough developers yet: your gut hasn't reacted.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why does compressing a whole GTM program into one day actually work, rather than just being a smaller version of the same thing?
I was originally pitching a four-week program breaking down the different aspects of building a DevRel program, and it just wasn't landing. On advice, I tried compressing the same services into a single day — and people said yes immediately. At first I thought, this is the same work, what's actually different? The answer is that we're all so busy, especially dev tool founders, juggling limited resources and time. It's much easier to block out one full day on your calendar and get a result than to continually chip away at something over weeks through scattered meetings and coaching sessions that never quite add up to a bigger picture.
What can someone realistically expect to get out of a single day?
The objective is a focused DevRel strategy for the next 90 days — not a finished go-to-market motion, but real clarity on what you're doing, why, and how it meets your goal. A common failure mode is trying to be everything to everyone — this for this persona, that for that persona — which just spreads you too thin. The day forces you to pick one very specific use case and audience. Early-stage dev tools tend to have fewer moving parts to untangle than a mature product with five SDKs and four kinds of APIs, so you can genuinely get a lot resolved in a day precisely because the surface area is still small.
What do you mean by "problem fit" as the foundation everything else sits on?
It's the same idea people call product-market fit or problem-solution fit — you solve a real problem, and that problem is a fit for a specific developer. It's not enough to identify who has the pain point; you need who has the pain point, the money, and the willingness to actually pay and adopt your tool because it's a genuine thorn in their side. With one client, Arcjet, we looked at e-commerce, new SaaS products, and AI/ML — and AI/ML stood out clearly because those teams have real cost pressure from GPU usage, which lined up with a genuine, painful need rather than just a plausible-sounding audience.
Beyond problem fit, what are the other pillars of the framework?
Discoverability — where are the developers, and how do you get your tool in front of them authentically. Credibility — building real trust, which is essential with developers specifically. The moment — the point where someone looks at your homepage or docs and thinks 'yes, this might be the solution for me,' which has to arrive as fast as possible so they actually adopt and try it. And advocacy — not hiring a developer advocate, but serving customers so well that they become advocates themselves: giving feedback, building integrations, writing code samples, telling other developers about you, because your tool fits into their existing workflow rather than asking them to change it.
How many developer interviews does someone actually need before running a sprint like this?
It depends more on interview quality than raw count — you need to understand a developer's workflow end to end: what they start with, what they end with, what tools sit in between, and the small, easy-to-miss pain points along the way. Adam Frankl's book suggests around 50 people by the end of a technical advisory board process, and I don't disagree — more is better. But if someone needs a bare minimum to sit down and work through a sprint day, I'd say five to ten, weighted more heavily toward existing customers than prospects if you have any, since customers are already using your tool and their signal matters more.
How do you know when you've actually talked to enough people?
If it doesn't appear in your gut — that moment of real conviction, maybe even triggering a difficult conversation with your co-founder about a feature pivot — you haven't interviewed enough people yet. With one client in the MLOps space, we had a strong hypothesis already, but a single additional developer conversation at an event surfaced a workflow mismatch we hadn't accounted for, and that one conversation changed what we prioritized. The work of a good interview also matters as much as the number — what's the actual job the developer is trying to get done, and where exactly does today's process create friction they might not even fully register as painful yet.
Can you give an example of choosing a smaller, more specific market over a bigger, more obvious one?
With one dev tool, the more obvious tech-stack fit pointed toward a frontend developer persona — but all of the existing docs, guides, and examples were built for a backend audience. Even though the frontend market looked like the bigger opportunity on paper, we didn't prioritize it, because of how much work it would take to build credibility from scratch there — new docs, new integration partners, developer quotes and case studies that actually spoke to frontend developers. Instead we niched into a specific part of the backend audience we already had credibility with. Most founders resist narrowing like this because they want a huge total addressable market, but taking the leap into a smaller, focused market is usually the right call.
What does the second half of the sprint day actually involve, once you've settled on a use case?
You have to go be that developer, or find one and watch them. If it's an AI/ML use case, you put on that hat and actually do the job the way that developer would, or better, get an eager prospect developer to run a screen-recorded developer-experience audit — using your tool to do their actual job while narrating what they're hitting. It's remarkably enlightening for a founder to watch someone else try to use their own tool, because you understand it because you're in it every single day — but you're using it as yourself, not as the developer you're trying to reach. Sometimes the first sprint with a client ends up being entirely about fixing developer experience gaps, before there's any point investing in discoverability, because if people don't trust you or reach that moment of confidence when they land on your site, you lose them before marketing even matters.
What's your advice for someone about to attempt this on their own?
Write the quick email template, make the list of people you actually want to talk to, and put a specific day on the calendar with a scheduling link — then just send the messages and let people book themselves in. That removes the ongoing pressure of continually chasing time for it. When people show up, have your questions ready and actually absorb what they say. Developers are some of the most straightforward people to serve, honestly — they want to learn, and they want to be able to say 'I built that.' Give them that chance and understand their real pain point, and you'll know exactly what to build and how to build it.