Building is easy now. Knowing what to build isn't
I recently read a post by a product designer that will probably sound familiar. A friend of hers is hooked on vibe coding, building apps by asking an AI for them in plain language. In a few hours he has something that looks good, works and feels like magic. He shows it to people who aren't designers and they're genuinely impressed.
She gets it too. But when she looks at that screen, she sees everything behind it that nobody has worked out yet:
- Why are we solving this problem?
- Who are we solving it for?
- What happens before and after this screen?
- What should the user see first?
- What happens when things go wrong?
- How does this fit into the business?
- How will we know if it worked?
"The question isn't just whether you can build it, but whether you know what should be built in the first place."
She illustrated it with a very clear image: to someone who isn't a designer, product design is two pieces, the interface and "make it look good". To a designer, it's a tower of fifteen: user research, framing the problem, strategy, information architecture, flows, testing, working with developers, data, go-to-market and, at the very bottom, business impact. The interface is just one of those pieces.
What it looks like from outside
- UI design
- Make it look good
What it actually is
- User research
- Problem framing
- Strategy and roadmap
- Information architecture
- Flows and wireframes
- UI design
- Interaction design
- Design system
- Prototyping and testing
- Stakeholder management
- Working with developers
- Data and metrics
- Iterating on feedback
- Go-to-market
- Business impact
I've lived it from the other side
I'm not a designer, but I recognise myself on both sides of this story. I'm one of those people who get excited building things with AI: this very website was made that way. And it's true, the first version takes an afternoon.
But at BMW I learned that a great part is useless if the process around it doesn't work. And at Laborai I saw it every day. Building internal tools with AI was fast. The hard part was deciding which ones were worth it: which task took the most time from the team, what happened when the AI got a client's tax return wrong, and how we'd measure whether we'd really saved anything. The tools that failed didn't fail because of the code. They failed because they solved a problem nobody had, or solved it for the wrong person.
And there's a problem that comes right after, and it's going to multiply. When building is this easy, everyone ends up making their own tools: a spreadsheet with macros here, a script there, and now an app built with AI in an afternoon. Each one makes sense to whoever made it. But nobody looks at the whole picture and decides which ones are best, which deserve further development and which should be centralised for the whole team or company. The result is ten versions of the same effort, none maintained and none shared.
That was exactly what I had to solve at MEWS Partners. I researched the existing tool ecosystem, who used what and for what, and proposed a governance model: clear rules for deciding which tools get supported and developed further, which get centralised for everyone and which get retired. The point wasn't to stop people building, but to make sure the best of what they built reached everyone.
Where I think this is heading
Over the coming months I think we'll see four things:
- A flood of prototypes. Building a demo will cost almost nothing, so there will be a huge number of them. Showing something that works will stop impressing anyone, just as nobody today is impressed that a presentation has charts.
- Value moves up the tower. The questions above, why, for whom and how we'll know it worked, will be worth more than ever. People who know how to ask them, whether designers, engineers or operations people, will be the most sought after.
- Governing what gets built. Companies will go from a handful of official tools to hundreds built by their own employees. The ones that make the most of it will have someone looking at that whole ecosystem and deciding what becomes the standard for everyone.
- More abandoned products. If launching is cheap, so is launching things nobody needed. The winning companies won't be the ones that build fastest, but the ones that drop what isn't worth it earliest.
For me the takeaway is simple: AI has given us an incredibly powerful engine. But an engine without a pilot, a flight plan or a destination isn't a plane.
A question for you: the last time you built something with AI, how much time did you spend deciding what to build, and how much building it?
The idea and the tower image aren't mine: they were shared by a product designer. The opinion and predictions are mine.
← Back to the blog