I’ve been Head of Design for a decade now. In that stretch, I watched an app I worked on reach 24 million monthly active users across Southeast Asia, shipped multiple products from zero to one, and managed UX designers, researchers, product owners, and data analysts in startups, MNCs, tech companies, and government-linked organisations.
More recently, I coached the end-to-end build of enterprise AI adoption customer service AI, and technical training AI with video recognition. These are products that were created through an internal incubation programme that I led, while AI was not the focus of the incubation, AI was a popular trigger for new products. On the side, I’ve built and launched a handful of my own apps with AI, the main one being an ESG comparison and insights site, plus a few social apps purely for fun.
I lay that out not to flex but to set the frame: I’ve built things before AI, through AI, and now. Here is what I actually think about where UX and product development stand.
1. Someone with intuition still has to decide what to build
Building a new feature is a mix of two things. Past data, which gives you a certain level of confidence. And vision, which is what comes from having built things before. You can’t create purely from what has already happened that’s an oxymoron. New means there’s no precedent to copy.
But you can’t run on blind faith either. The discipline is admitting that things can go wrong, that you cannot predict the future, but you know how to proceed anyway. That knowing how to navigate uncharted territory and convincing teams to come along is the art to master.
This is exactly where AI hasn’t delivered. It’s genuinely good at a lot now. It has not given anyone clarity on what’s next. That call still belongs to a human with scars.
2. Lean Startup aged well — better than well
The Build–Measure–Learn loop has an elegance and completeness most product frameworks never reach. And it’s more relevant now, not less.
Here’s why. Build at least the engineering slice used to be the bottleneck. Now that launching an MVP is easier than it’s ever been, the center of gravity shifts to Learn figuring out the right thing to build in the first place.
Which brings me to how we figure this out. There’s serious talk right now about “simulated” humans synthetic users you interview instead of real ones. Seriously? You have a problem talking to a human? If you would rather learn from a simulated human than a real one, you are not a user researcher, and you have no business doing user research. There. I said it.
If a simulated human is genuinely easier and faster to deal with than a real one, your research process is broken and running far too long. The Google Design Sprint compresses user interviews into a single day. That’s been my de facto cadence since my startup days, and I’ve shipped many successful features on it. One day of research? Purists balk my own researchers certainly have. I offer it as a counter-reference point. I’ve watched too many consultancies and research agencies stretch research well past the point of usefulness often to justify the fee. Stop. You’re harming the craft.
One of the first AI products SP Group launched is the clearest case for Lean Startup I have. Product Sage is an AI chat that reads a customer query, crawls our own protected data and a set of vetted external sources, and drafts an answer for our customer service agents to work from.
Going in, we had three real unknowns: what the AI could actually do, whether it fit the problem we were solving better efficiency for agents, better answers for customers and whether agents would adopt it at all.
Lean is what cut that down to something testable. Instead of trying to answer every customer query, we pointed the AI at the top ones about 40% of total volume. Instead of rolling out to the whole customer service centre, we picked a small set of beta users to train the model and show us where adoption broke. Then we watched the adoption journey closely, found the parts that failed, and iterated.
3. Don’t conflate Measure and Learn
The strongest argument for simulated data is that it gives you more data points. True but it arrives at the wrong step of the loop.
Measurement is the quantitative step, and you want it statistically significant which means it should be built on concrete, real data, not synthetic stand-ins. Learn is the qualitative step; it’s where you find out why. And that’s the part simulated humans can’t touch. They can’t read the ease or tension in the room, or the cultural nuance where a yes means maybe and a harsh critique is actually a passionate user. Don’t collapse the two into one thing it is not hard to do user research if you are good at it.
With Product Sage, the learning happened through contextual inquiry: we sat beside individual customer service agents and watched how they worked, with and without the AI. No simulation gives you that.
The real win from AI is elsewhere: the cost of Build has dropped so far that you now reach Measurement faster than ever. Brainstorming and prototyping is much easier. Take that win. Don’t contaminate the Learn step trying to squeeze more out of it.
4. The frameworks that survive disruption are the ones worth keeping
The new complexity is uneven AI literacy people are operating at wildly different levels of fluency, and that gap creates friction that didn’t exist before. But the underlying technological trends still apply.
And here’s the test I keep coming back to: how do you know a process or framework was actually well thought out? It stands the test of time even through massive disruption. Lean Startup passed. Technology adoption lifecycle persists. Agile is more important than ever.
This is what my stand is, at this point. Check in again in 3 months
