Faster execution exposes bad thinking. It doesn't fix it.
Editorial insight
Every day, you log in at LinkedIn and it tells us AI just changed everything again. Design. Development. Research. Strategy. And honestly? It's not wrong.
But there's something missing from most of those posts. They talk about what AI can do. They rarely talk about what it can't replace: the part where you figure out what's actually worth building, and why.
Speed is easy to measure. Direction isn't. And right now, a lot of teams are moving faster than ever toward the wrong thing.
Now, the question we must ask ourselves it's whether you're building the right thing at all, and not how fast you can build.
Value piece
AI in the room before you start building
Teams that get the most out of AI in product development are using it earlier, before a single line of code is written.
That shift matters more than it sounds. And here’s why.
The discovery phase has always been the most expensive place to be wrong. Assumptions that survive into development become features nobody uses. Features nobody uses become products that don't work. AI doesn't eliminate that risk, but it does change the economics of it.
When you can prototype an idea in hours instead of weeks, you can test more assumptions before committing. When you can generate interview guides, validation frameworks, and competing hypotheses in minutes, the conversation about what to build becomes richer and earlier. The cost of being wrong drops. The cost of not finding out goes up.
But AI doesn't decide what's worth learning.
This is the part that gets lost. A faster prototype is only useful if it's testing something that matters. An AI-generated PRD is only useful if the thinking behind it is sound. More output, produced faster, amplifies whatever direction you've already chosen, good or bad.
The teams building with the most clarity right now share something: they use AI to accelerate the discovery loop, not to skip it. They come in with clear hypotheses. They define what validation looks like before they test. They treat AI as a way to get to real user feedback faster, not as a substitute for it.
What this looks like in practice:
Use AI to generate competing framings of the problem before aligning on one
Build low-fidelity prototypes early to surface assumptions you didn't know you were making
Let AI draft the research artifacts, then interrogate them like you would any brief
Treat speed as a way to run more experiments, not fewer conversations
The barrier to building has never been lower. That's not the advantage most people think it is. The advantage goes to the teams who use that speed to learn more, not to the teams who use it to decide less.
Untile Picks & Trends Radar
Two readings that we think are worth your time this month:
→ Vitorino took a startup from a discovery session to a working proof of concept using AI tools end-to-end, including the parts that didn't go as planned. If you want to understand what "AI as a multiplier" actually looks like in practice, this is the most honest version we've seen. Read Vitorino's breakdown.
→ David Hoang on how product discovery changes when you can build anything, immediately. His argument: discovery doesn't get less important, it gets more important. And the hard part was never synthesising research. It was getting the right insights in the first place. Read "How Product Discovery Changes with AI".
Case Studies
When the brief is wrong
From early discovery sketches to a focused billing CRM.
The brief changed, the outcome didn't.
Arturai came to us with a clear request: digitise all internal processes. They had a list, a timeline, and a budget. On paper, it was a straightforward project.
But we didn't start building. We spent two weeks in discovery: mapping workflows, talking to the people doing the actual work, looking for where things were really breaking down.
What we found changed everything about the scope, the solution, and the timeline.
The result was a focused MVP, delivered fast, within budget, and solving the problem that actually mattered. Billing processes that used to take minutes now take seconds. Time savings of over 50%.
But the more interesting question is what would have happened if we'd just built what they asked for.
Inside Untile
The next Open Days is on May 28, at the Untile office. See you there.
What we’ve been up to lately:
→ Abel Soares, our Head of Engineering, wrote about what it actually costs to integrate AI into an engineering team. Not the tools. The standards, the documentation, and the transition period nobody plans for. Read the article
→ Our next Open Days is on May 28, at the Untile office. The topic: how large organisations experiment with new ideas without putting their core business at risk. Register here
From the team
“AI didn't make us faster on its own. What really saved time was doing the hard discovery work first, then using AI to narrow the gap between validated insights and a working proof of concept. Without that foundation, AI speed quickly turns into an illusion. More activity, but not necessarily more value.”
Till next month!
The right problem is worth finding.
Most teams don't fail because they build badly. They fail because they build the wrong thing, and only find out later.
Discovery is where that changes. It's the work that makes everything else worth doing.