Digital Product Talks #37: Why AI Hasn't Made Your Team Faster

And yet, for some, the product release date has not moved. Why?

We took a deeper look into this topic with Ivonne Gassmann, the Chief Products & Innovation Officer at Hays, on the last episode of Digital Product Talks. Hays has had AI running through its processes for a long time now, so when I asked her what companies get wrong about all this, she had an answer ready.

Anyone can buy an AI tool, nobody can buy adoption

Ivonne’s first point was about the expectation of introducing a new tool into the workflow, and the reality of getting anything out of it. It’s easy to introduce a new tool, but getting an organisation to use it is a whole different beast.

In her experience, somewhere between 40 and 50 percent of people pick a new tool up immediately, another 30 percent get there over time, and some simply stay sceptical.

Anyone who has rolled out a design system will recognise this. The launch goes well, everyone is happy and optimistic, but some time later half the team is building screens from scratch again. As it turns out, maintaining the tokens was nobody's job, and the documentation went stale very quickly. So the system was not the problem, it was the habits around it.

But let’s get to Ivonne’s second point: most organisations put AI at single points in a chain. Meaning, they’ll introduce a tool or an assistant somewhere. In theory, it’s better than what it replaced, but what almost nobody does is look at the connections between those points.

So despite introducing a tool that should speed up the whole process, in reality every step accelerates in isolation while the connections between them stay as slow as they ever were.

"Don't think stand-alone, think connected. What does my process look like, where are the handover steps inside it?" Ivonne Gassmann, Chief Products & Innovation Officer at Hays

We've experienced this at COBE as well. For example, our UX researchers started using AI to speed up analysis, and it did, but it continued going into a repository designers didn't open, just more of it. The problem is, a designer in the middle of a concept will often not stop, switch tools, and go hunting for a research finding. It's too inconvenient, so the research kept dying in the same place it had always died.

The thing that solved the issue wasn't a faster research step, it was turning findings into something more convenient – How Might We (HMW) statements. Rather than a simple conclusion of the research, the HMWs land in the designer’s environment already framed as something the designer can act on. 

The same story plays out in other roles. Developers using agentic tools can produce more code, but this moves the bottleneck to review. If nobody redesigns how review works, you've got a bigger queue at the gate. Which is a nice problem to have, but how do you resolve this?

So these aren’t tooling decisions, they are process decisions, which is boring work difficult to present as a nice number in a slide. But that’s where you’ll find the most value in introducing AI.

Why nobody gets to redesign their whole process

I asked Ivonne what she'd do differently if she could throw everything out and start fresh. Starting from nothing would be wonderful, with no old system to work around or something that's "good enough" for someone to defend in a meeting. You’d just build exactly what's needed.

Unfortunately, that’s not really available to anyone reading this, and Ivonne said so herself – a clean start stays a dream. The real question is how do you move things forward inside a company that's already been running a long time? How do you cut or change the habits everyone’s become comfortable with over the years? Her phrase for that was alte Zöpfe abschneiden, or cutting off the old braids, which is a German phrase to describe a habit that has outlived its usage.

This is why "redesign your whole process" is useless advice. Nobody gets to do that. What you can do is pick at the bits and pieces that annoy your team most and take those apart. Taking away the aspects they like, and too much at once? It’s just throwing money at the wind.

Where to start with AI in a process that already exists

Going back to the release date mentioned at the start – how fast each team works on its own mostly doesn’t move it. Time from a research finding to a design decision does, or time from an approved design to merged code.

So, when you want to introduce a new tool to improve an existing process, make sure to keep adoption in mind. You can pay for it, but nobody will use it if there isn’t a good case for it, because most people prefer to stay in their comfort zone.

Unfortunately, nobody is going to hand you a clean slate. So a good idea is to pick one issue your team complains about most, and rebuild that. A whole-process redesign is a nice idea that never survives contact with reality.

If you want a second opinion on where your process is losing time, we're around.

Want to hear the full conversation with Ivonne Gassmann? Listen to the episode on the Digital Product Talks podcast on Spotify or Apple Podcasts.

‍

TL;DR

In a rush? Worry not, we've prepared a quick summary for you.

Why hasn't AI made our delivery faster? Because the speed gains land inside individual steps while the handovers between them stay untouched. If research still doesn't reach designers, a faster research step changes very little.

What do companies underestimate when adopting AI? The distance between installing a tool and getting value from it. Anchoring it technologically is a project with an end date, while getting an organisation to use it is a change process without one.

What's the most common mistake when adopting AI in product development? Treating it as a tooling decision. Choosing where the AI goes is the easy part, but redesigning the handover is the part that moves a release date.

Where should we start if we can't redesign the whole process? Start small. Pick the problem your team complains about most and rebuild that, rather than waiting for a clean slate that isn't coming.