Guest
Co-founder and CEO of Andsend, former CTO of Zapplify
Kevin told me his team runs daily sprints. Not weekly. Daily. Each standup is basically a sprint planning session for the next 24 hours. My first reaction was: that sounds exhausting. My second reaction was: wait, how does that even work?
Turns out, they’ve built something he calls an “iteration factory.” And the results are wild.
The Old Way Was Broken
Kevin’s previous company, Zapplify, ran textbook Scrum. UX designers, engineers, QA, product managers. One week sprints. Backlog with stories and epics. Everything looked great on paper.
“The problem in that type of organization is of course that you end up creating a lot of bottlenecks. That’s one aspect of it, from a performance perspective. But of course, the engineers are also very unmotivated.”
When they mapped out all the bottlenecks, the numbers were absurd: a team of nine was losing roughly 40 days per week in handoffs and lead times alone.
That’s when Kevin started asking a different question. Instead of optimizing the existing process, what if they built a factory designed to spit out iterations? Fast iterations. Daily iterations.
Killing the Backlog
The first big move was painful. They deleted Jira. Not metaphorically. They actually removed everyone’s access.
“I was still during the nights in the beginning, sitting with my computer and looking at this perfectly structured project in Jira and just enjoying the structure and also crying a bit that we will have to let this go now.”
I laughed, but I get it. There’s something comforting about a well-organized backlog where everything is planned and prioritized, even when it’s all wrong.
Because here’s the thing: when you have a product manager as gatekeeper for everything, with sprints planned in advance, you can’t actually respond to what you learn. You’re executing a plan, not solving problems.
“That was the enabler for all of this. Suddenly everyone realized that we don’t know what to do anymore.”
And that’s exactly the point. Not knowing forced everyone to figure it out together.
Hypotheses, Not Features
The language shift matters. At Andsend, nobody works on features. They work on hypotheses.
“We have daily sprints. So every standup is basically a sprint planning for the day. The mindset shift is very interesting how everyone just thinks about, today we should get this hypothesis to production.”
A hypothesis looks like this: “Introducing a product video in the hero section on the website should increase the number of activated users.” Clear input, measurable outcome, and you can test it today.
They deploy on average more than one new iteration per day per engineer. Some hypotheses are product-facing. Some are deeply technical, like “if we introduce these three dimensions to our vector space, that should increase clicked cards in the feed.”
The technical ones still tie back to user behavior. That’s the key.
Engineers Who Actually Talk to Customers
This is the part that made me jealous. Every engineer at Andsend is in customer meetings. Not optional. Not occasionally. Regularly. It’s what turns engineers from ticket takers into problem shapers.
“Nothing makes you feel as much ownership as if you meet the customers, you feel the problem. You don’t just see it, you feel the problem by actually creating a connection with the customer and making a promise to the customer.”
They’ve even experimented with engineers owning customer relationships entirely, handling follow-ups and everything. The goal is everyone in one to three customer meetings per week.
Why does this matter? Because when you make a promise to a real person, you ship differently. You’re not implementing a ticket. You’re keeping your word.
Filling the Gaps with AI
I asked the obvious question: how do backend engineers suddenly become competent at UX?
Kevin’s answer: AI fills the gaps. They gather all customer interview transcripts in folders, then ask AI questions about patterns across conversations they haven’t personally attended. They can marry qualitative insights with quantitative data before writing a single line of code.
For design work:
“We actually don’t use Figma at all anymore. We only use tools like Lovable or even just prompted away in Cursor. We make it on our local and then share it to the rest of the team.”
No Figma at all. Product engineers generate prototypes in code-first tools and iterate from there—a shift that’s changing how we design products.
The Tesla Analogy
When I asked about scaling, Kevin pointed to Tesla’s factory:
“In a Tesla factory, the engineers work exactly like this. They go out in the production, they have hypotheses, they make a change, and they observe metrics and document your change. They can do that in a day and then watch what happens.”
Tesla’s goal is apparently one car every 10 seconds. They’re at one every 90 seconds now. Still insanely faster than competitors who don’t operate this way.
The key to scaling isn’t adding more process. It’s observability. Everyone needs to know what changed yesterday without a bunch of meetings to find out.
So You Want to Try This
Kevin’s advice for leaders considering this shift:
First, challenge yourself on why you want to do it. If it’s because you read about it and it sounds cool, it probably won’t work. You need internal conviction.
“Something like this is something you have to sort of internally build a conviction around and a belief in.”
Second, write it down. Use AI to stress-test your thinking. Ask it to respond as an engineer reading your document. Then as a CEO. Find the trade-offs. If you can’t find any, you haven’t thought hard enough.
Third, find your champions. There are always one or two engineers who naturally get this. Back them. Amplify their successes. When they ship something fast and it works, make sure everyone knows.
“First and foremost, you got to understand why you’re doing it yourself. And if it’s just because you read it and it looks cool, it’s probably not going to work.”
Could my team run daily sprints? Honestly, I don’t know. But after talking to Kevin, I’m more curious about what’s actually blocking us from trying.
