The hardest part of innovation is no longer building

Reading time: 7–9 minute

‍

‍

I was recently at the Mobile World Congress and 4YFN in Barcelona. Over 1,000 startups on the floor. Investors representing €70 billion in funds. Scheduled conversations, corridor conversations, and a few that ran for two hours without anyone noticing.

One idea kept coming back across almost all of them, regardless of whether I was talking to a founder at an early-stage booth or someone running innovation at a large corporate.

Building technology is no longer the hardest part of innovation. Deciding what should be built in the first place is.

That shift might sound subtle. But it has a concrete consequence for how teams should be spending their time, and it starts well before a single line of code is written.

In short

As building becomes faster and cheaper, the real risk in product development has moved earlier. The teams that succeed in this phase won't be the ones who build faster. They'll be the ones who validate assumptions before committing to development.

Key takeaways

• When building becomes easier, risk moves earlier in the process, into ideation and validation.
• Most startups at 4YFN are not building new AI models. They are applying existing capabilities to problems they understand well.
• Differentiation is shifting from technical ability to domain knowledge and problem clarity.
• The ideation phase is where the most expensive mistakes are either caught or missed.
• Deciding what not to build is as important as deciding what to build.
• The founders who stood out opened with a specific problem. Not a technology.

‍

Building has become the easy part

For a long time, the biggest barrier to innovation was execution. Building software required time, specialised teams, and significant upfront investment. That constraint forced a kind of discipline, you had to be reasonably sure before you committed.

That constraint is largely gone. Cloud infrastructure, modular frameworks, and accessible AI tools have lowered the barrier to building digital products dramatically. Small teams can prototype and test ideas in weeks rather than months.

Which sounds like good news. And it is, mostly. But when building becomes easier, something else happens: the pressure moves. It moves earlier in the process, into the decisions that happen before development starts. And most teams are not set up to handle that shift well.

Faster tools shift risk, they don't remove it

Teams can now create convincing prototypes quickly. AI tools can simulate workflows. Product concepts can be visualised and tested before a full system is built. Used well, this is a genuine advantage.

But what often happens instead is that something works technically and the team moves straight into development. The prototype looks credible. The demo goes well. The momentum builds. And months later, they discover that the real challenge was never technical feasibility, it was whether the problem was meaningful enough to solve.

The ideation phase is where that uncertainty can be reduced, if it is treated seriously. What I saw at 4YFN made it clear how often it is not.

What the founders at 4YFN were actually building

The pattern that stood out most clearly at 4YFN was this: very few startups were building their own AI models. Instead, founders were applying existing capabilities to problems they understood well. Healthcare, legal workflows, logistics, operations, customer service.

The technology was often already available. What separated the companies that felt credible from the ones that did not was something else entirely, and it showed up in the first two minutes of almost every conversation.

The founders who opened with a problem

The conversations that stuck with me started the same way. A specific industry. A specific person experiencing a specific friction. A clear answer to the question: what actually changes if this works?

These founders had done the work before writing a line of code. They had spent time in the environment they were building for. They understood the workflow well enough to know where the problem actually sat, not where it appeared to sit from the outside. That clarity showed up in how directly they could answer almost any question about traction, users, and next steps.

The founders who opened with the technology

The contrast was visible. Some teams led with what they had built: the model, the integrations, the infrastructure. Impressive work, often. But when the conversation moved to the problem being solved, the answers became less specific. Agentic AI was the phrase of the week. Most people using it could not define what their agent actually decides autonomously, or who specifically benefits from that, and why.

That gap between technical capability and problem clarity does not emerge during development. It emerges during ideation, or rather, when ideation is skipped. Which raises the question of what good ideation actually looks like in practice.

Innovation needs better questions before it needs better tools

The ideation phase is not simply about generating ideas. It is about asking the right questions before committing to development.

Does this problem exist in the way we think it does? Who actually experiences it? How frequently? What changes if it disappears?

These questions sound simple. Answering them properly often determines whether a product gains traction or struggles to find its place. And yet most teams move past this phase too quickly, either because the pressure to build is strong, or because slowing down to validate feels less productive than making progress.

At Untile, this is a space we focus on directly, helping teams validate ideas and assumptions early, before committing significant resources to development. The pattern we see repeatedly is that the teams who invest in this phase make faster, more confident decisions later. But asking the right questions is only one part of what the ideation phase needs to do. The other part is harder to talk about: knowing when the answer is no.

Deciding what not to build

Innovation is often described as the process of creating new things. In practice, a large part of it is deciding what not to build.

Handled well, the ideation phase reduces risk and gives teams confidence in the direction they choose. Handled poorly, it quietly sets organisations on a path that never needed to begin.

What it looks like when ideation goes wrong

The pattern is consistent, and I saw versions of it across the event. A team identifies a space that feels relevant. Someone builds a prototype quickly, which is now straightforward. The prototype works technically, early feedback is positive, and the team starts treating that as validation of the idea itself.

It is not. A working prototype tells you the technology is viable. It tells you very little about whether the problem is real, whether the people experiencing it will change their behaviour to solve it, or whether the product will find a market. Those questions require a different kind of work, slower, less visual, harder to demo.

What tends to happen instead is that months of development build up around an assumption that was never properly tested. By the time the real challenge becomes clear, the cost of changing direction is significant, not just in time and budget, but in the accumulated momentum and internal alignment that has formed around a product that does not fit.

The teams that avoided this at 4YFN were not necessarily smarter or better resourced. They had simply done the uncomfortable work of stress-testing their assumptions before treating them as facts.

What a week at MWC reinforced

The corridor conversations at MWC and 4YFN are often more revealing than the scheduled ones. What came through consistently,across founders, operators, and corporate innovation teams, was a shift in where the real difficulty sits.

The advantage in technology is no longer primarily about what you can build. It is about how clearly you understand the problem you are trying to solve, and whether you are willing to test that understanding before committing to development.

The teams doing that well are not necessarily building faster. They are building with more confidence in what they have decided to build, and with a clearer sense of what they have decided not to.

That work happens in the ideation phase. It is where the most expensive decisions are either made well, or deferred until they cost significantly more to correct.

‍