Guest: Anders Fredriksson, serial startup founder, author of Speed: Optimizing Startups for Speed of Iteration, and co-founder at Staer.
You can also watch the interview on Youtube:
Anders was named Sweden’s most prominent internet entrepreneur in 2007. He didn’t know the word “entrepreneur” meant starting companies until he was 24. In Swedish, it’s the same word as building contractor.
That detail tells you everything about him. He figured things out by doing them wrong first.
You Have a Known Problem and an Unknown Solution
That’s the frame Anders uses to explain why traditional startup planning fails. You know there’s a problem. You have a rough idea of where the solution might be. But you don’t know what it looks like.
So what do most teams do? They plan the whole route to a destination they can’t see.
Anders’s argument is simple: don’t plan the whole way. Plan one step. Check if you got closer. Plan the next step. The faster you run that loop, the better your odds of finding the actual solution—or discovering there isn’t one before you run out of money.
“Instead of thinking of a single solution that you think, okay, this is what we need to do, you essentially create a machine that allows you to try and test all possible combinations of solutions. And then if there’s only one left, then that must be the best one.”
Killing the Backlog
At Andsend, the company where Anders fully implemented his methodology, there’s no backlog. They removed it completely. Features became experiments. Sprints became daily. The question at the start of each day isn’t “what are we building?” It’s “What hypotheses are we testing?”
I remember Kevin Östlin, CEO of Andsend, telling me about this on a previous episode. It sounded exhausting at first. Then it started sounding like the only thing that makes sense.
Anders adds the organisational layer: everyone owns end-to-end. No product manager translating business goals into tickets for engineers. No engineers waiting for someone to define the problem.
“You define what’s called a one metric that matters, that aligns the direction of everybody in the company. Everybody in the company can then come up with ideas that they believe will move that metric. And they have the authority to implement that end-to-end.”
Build it. Push it to production. Check the metric. Roll back or improve. Repeat.
The uncomfortable part: developers have to talk to customers themselves. You can’t outsource that anymore.
The PR Is the Bottleneck
The biggest pushback Anders gets when implementing this methodology? Killing pull requests.
His case is methodical. An async code review means developer A finishes work, opens a PR, and switches context to something new. Developer B gets interrupted, eventually reviews it, and leaves comments. Developer A—now deep in something else—has to context-switch back. Both people pay a cognitive tax, and the code sits idle the whole time.
“Pool requests is one of the biggest bottlenecks in that process. If you want to minimize the time from coming up with a feature until that feature is in production, it turns out that pull requests is in the way.”
The alternative he pushes for: synchronous code reviews. Pair programming. Review as you go, push when it’s done.
I know the reflex here. Two people on one task feels inefficient. But Anders has the data from Zaplify, Kevin’s previous company: they went from one deploy every two weeks to 30 deploys per day after the methodology was fully in place.
Thirty deploys a day. That number should reframe every conversation you’ve ever had about “moving fast.”
Save to See
One exercise I’m stealing and running with my own team is what Anders calls the save-to-see latency workshop.
Write down every step in your process from “developer has a feature idea” to “that feature is live in production.” Be ruthlessly specific. Save the file. What happens? Does a dev server hot-reload in milliseconds, or does a library PR need to be merged first? Map it all. Then multiply each step by how frequently it happens and how many developers it affects.
“Changing the time it takes from a file change to seeing the change—from 30 seconds to 100 milliseconds—has an enormous impact if you do that a hundred times per day and you have a hundred developers.”
Four-hour builds look terrifying on a timeline. But if they happen once a month, they might not be your real bottleneck. The three-second save-to-see delay that happens ten thousand times a day? That one’s silently destroying your velocity.
With AI writing code faster than ever, these friction points become multipliers. You’re shipping PRs at machine speed but still waiting days for reviews. The math gets ugly fast.
Generalists Are Going to Win
Anders has a strong view on hiring that connects directly to the methodology: specialists are a liability in early-stage startups.
Not because they’re not good at what they do. Because the methodology requires everyone to own end-to-end. A frontend specialist who can’t touch the backend, can’t talk to customers, can’t think about the metric—that person is a constraint, not a resource.
His prediction: generalists, augmented by AI, will outperform specialists at most startup tasks.
“A generalist can fill in any gap they have with AI. And like if you really wanted to move to this methodology from an existing company where you have super structured teams that only do specific things, I’d recommend to sort of have everybody start slowly to move to full stack by adding AI as sort of the fill-in-the-gap layer.”
At Staer, his current startup, the team is 11 people, mostly experienced founders. Computer vision specialists who are also strong general engineers. Nobody has a lane they stay in.
The Machine That Builds the Machine
The question I’m hearing from engineers right now: if AI writes 80-90% of the code, what’s left for me?
Anders’s answer is the most grounded one I’ve heard. Engineers become the people who maintain and improve the machine that builds the machine. The agents are the machine. Engineers remove their bottlenecks, optimise their feedback loops, and make it easier for them to detect mistakes.
He uses Tesla as an analogy. Robots build the cars. Hundreds of engineers start their morning by checking a monitor: what’s the current bottleneck? They go to the station, reprogram the robot, deploy it, and measure. If it’s better, it rolls out to every robot doing that task. If not, they roll it back.
“I think there’s still a lot of work to be done for that. Like, can the agents actually see the thing? Can they have a fully running lab in the cloud that they can run in? So I think there’s still a lot of work to be done.”
If Tesla can run this model with hardware, we have no excuse not to do it with software.
The Lesson That Stayed
When I asked Anders what one thing an engineer or founder could do tomorrow morning to start improving their iteration speed, he came back to the bottleneck workshop.
Write it down. Every step. Feature idea to production. Calculate the frequency. Multiply by the time. Find the biggest number. Fix that first.
Don’t build a perfect machine and forget to ship the product. But don’t build the product while ignoring the machine either.
Anders crashed his first startup. He didn’t know what a CEO was supposed to do, so he spent his time writing business plans. That’s still where most founders start—planning the whole route to a destination they can’t see.
The faster you stop doing that, the better your odds.
