Utbenat: Fail Fast

Introduction

Sebastian:
Welcome to Syntra Utbenat. This is the podcast where, in ten minutes, we untangle the words and concepts circulating in the world of data and AI, and break down what they actually mean – with Sebastian Mildgrim.

The Expensive Dinner Party

Sebastian:
Imagine you're hosting a big, important dinner party on Saturday. Twelve people are coming over. You decide to go all out and cook an elaborate French seafood bisque from a beautiful cookbook you got for Christmas. You get up early. You buy fresh fish, saffron and a bottle of wine that costs a little more than you'd usually spend. You chop, you make stock, you strain and reduce. For six hours you stand at the stove, labouring over this massive undertaking.

When the guests sit down, you proudly ladle the bisque into beautiful bowls. You sit down, take your very first spoonful and taste it. And... it tastes like disaster. You accidentally mixed up teaspoons and tablespoons for the salt, and the wine you poured in had gone corked. It's completely inedible. There you sit. You've wasted an entire Saturday, burned through a lot of money, and your guests are starving. If you had just taken a small spoonful and tasted the stock after fifteen minutes... you could have thrown it out, laughed at the mistake and found a solution. But you waited six hours – and now only the pizza delivery can save the evening.

What "Fail Fast" Actually Means

Sebastian:
Today we're going to talk about what really went wrong with that seafood bisque – we're going to talk about the concept of Fail Fast. It's a term that often gets dropped into presentations by eager consultants, and one that's frequently misunderstood by leadership teams who think it means "we should fail". But in reality, it's about survival, prestige and the art of not cooking for six hours without tasting.

Fail Fast is a philosophy about risk minimisation. When we build new systems, launch an AI model or create a new data platform, we almost always build on assumptions. We assume users will want this feature. We assume data quality is good enough. Fail Fast means we need to build the smallest, cheapest version of our idea to test whether that assumption holds. And if it doesn't, we stop quickly. Before we've burned through the budget.

The Traditional IT Project

Sebastian:
Let's look at what reality often looks like inside our companies. We're incredibly good at starting projects. We put together a steering group, we write a multi-page requirements specification and we ask for a budget of a million. Then we lock the project team in a basement for six months to build a new AI assistant for customer service – or maybe a pricing tool for our contract customers in e-commerce.

When we then go to roll out the system with great fanfare... we discover that reality isn't quite what we expected. The AI assistant we built might give lightning-fast answers, but it turns out customers get frustrated because they really just wanted to speak to a human when their invoice was wrong. Or the new pricing tool calculates exactly the right discounts, but the e-commerce customers still don't log in – because they prefer to call their account manager and negotiate. We've built a technically perfect solution to a behavioural problem we completely misunderstood from the start. That's an incredibly expensive way to discover you were wrong.

Why We Don't Dare Fail Early

Sebastian:
So why do we do this? It comes down to human psychology and something called the Sunk Cost Fallacy – the trap of throwing good money after bad. But above all, it comes down to prestige. Say you're a few months into that project. The project manager starts to realise that the technical platform you chose can't handle the load. It's not going to work.

In a Fail Fast culture, the project manager would have pulled the handbrake immediately, gone to the leadership team and said: "We were wrong about one of our assumptions. The technology we chose isn't holding up. We're stopping – and we need to evaluate whether it's worth trying again with a different technology, or whether we should reallocate the budget to something else." But in a traditional corporate culture, failing is often career-threatening. The person who pulls the handbrake risks being scapegoated, rather than celebrated as the hero who just saved the company a fortune. Nobody wants to be the one who bursts the bubble. So instead of pulling the handbrake, you start patching and stitching. You bring in more consultants. You push out a half-baked solution just to have something to show, because you've already burned through a couple of hundred thousand. You end up running what's called a "watermelon project": green and glossy on the outside in every status report, but bleeding red on the inside. All because you didn't dare to fail early.

"Learn Fast" – What We Actually Mean

Sebastian:
Honestly, "Fail Fast" is a rather unfortunate name, because nobody likes the word fail. It creates fear. What we're really talking about is Learn Fast. How quickly can we gain new knowledge? In data and AI, this is especially important – because we rarely have all the answers when we start. We don't know how the AI will respond until we feed it our data. If we build everything before we test the data, we're taking an enormous risk. Applying this philosophy means shifting focus from "How quickly can we finish building everything?" to "What is our biggest and most dangerous assumption right now, and how can we prove or disprove it by next week?". Simply put: Fail Fast is really just about buying information. What's cheaper – paying ten thousand kronor now to find out the idea is bad, or a million in six months to learn the exact same thing?

The Solution: Break Down the Risks

Sebastian:
So, how do we break out of this behaviour? How do we stop building blind for months on end? It's about stopping treating projects as enormous monolithic blocks, and instead starting to isolate what we're actually uncertain about. We need to lower the threshold for testing and trying things. The easiest way to do that is to stop talking about 'requirements' and start talking about 'hypotheses'. Instead of saying "We're going to build a new system," we say: "We believe our customers want to solve this themselves online." When we frame it as an assumption, it suddenly becomes obvious that we first need to try and prove we're right – with minimum effort – before we start building.

Imagine walking into a really good Italian gelato bar. You look down into the display case and spot a new, rather unusual flavour. Let's say "Mango and Chilli". It looks intriguing. But do you immediately buy a gigantic three-litre tub of Mango-Chilli, take it home, invite the whole family and hope for the best?

No. You ask the guy behind the counter for a taste. He picks up a tiny pink plastic spoon, scoops up half a gram of ice cream and hands it over. You taste it. If it's awful, you drop the little spoon in the bin and say: "No thanks, I'll have vanilla." It cost you nothing, it took five seconds, and you avoided a major disappointment.

Today's IT projects are sorely lacking pink plastic spoons. Far too often, you go straight for the three-litre tub. Fail Fast is about handing out plastic spoons. Before you build a massive dashboard to show real-time sales figures, you could pull an export to Excel, draw a graph by hand and show it to your sales manager in a meeting. If the sales manager says "I couldn't care less about that metric" – you toss the spoon and you've just saved yourself all that development time.

What You Do on Monday

Sebastian:
Here's what you do on Monday. Look at your biggest ongoing – or upcoming – project. Ask yourselves: What is the biggest assumption we're making right now for this to succeed? Is it that the customer service team will actually use the new tool? Is it that the data in the old system is clean enough?

Once you've identified the most dangerous assumption, find a way to test just that thing in just a couple of hours of work. Sketch the tool on a whiteboard. Send a test email. Pull a manual list. Go out and let people taste the ice cream before you buy the ice cream factory. If you dare to throw out the bad flavours early, more of your projects will deliver real value – on budget and on time.

To summarize: Fail Fast isn't about being careless and failing. It's about learning quickly, killing prestige projects before they drain the cash, and always testing your most dangerous assumptions first. Stop cooking soup for six hours in the dark – and start handing out pink plastic spoons.

Thank you for listening to today's episode of Utbenat! If you want to talk more about today's topic – or just talk data – get in touch. You'll find us on LinkedIn. Or contact us through our website. See you next time – and take care out there!

You've been listening to Syntra – a podcast from Fiwe.