Product Delight in Paris: A Workshop About More Than Shipping Fast

AI can make a product functional very quickly. That does not make the product worth caring about.

This is the uncomfortable opportunity of faster building. When everybody can produce a credible first interface, “it works” becomes the floor.

In Paris, we ran a workshop around the work that begins above that floor.

From an idea to a felt experience

On 9 June, product managers, designers, founders and first-time builders joined us for the Lovable × Product Delight Workshop. Elena Avramenko and I co-hosted it with Nesrine Changuel and the Miro Community Team, with support from Amplitude, Hexa and Miro.

The intention was practical: participants would leave with a working prototype, the Product Delight framework and a clear next step.

But the workshop was not about adding charm after the useful work was done. Delight is not confetti, a clever loading state or a friendly sentence placed on top of an indifferent product.

The deeper question was: what does the person need to feel for this experience to become meaningful?

Utility is necessary and increasingly common

A functional product resolves a task. It helps someone book, decide, organise, create or communicate.

AI-assisted tools such as Lovable have lowered the cost of reaching that level. This is good. More people can turn an idea into something concrete without waiting for a full delivery cycle.

It also means functionality alone is a weaker source of differentiation. If another team can recreate the visible feature in a weekend, the advantage has to live somewhere else: in the problem chosen, the trust earned, the context understood or the emotion the product helps create.

That is why Product Delight felt so relevant to an AI-building workshop. Faster execution gives teams more room to explore the experience—if they resist spending all the saved time on more features.

Delight starts before the interface

A participant can ask an AI builder to add animation, gradients and conversational copy. None of those choices tells us whether the product respects the user.

We asked teams to begin elsewhere:

• What is the person trying to achieve beyond completing the task?

• What anxiety, effort or uncertainty surrounds that moment?

• What would make them feel capable, recognised, safe or pleasantly surprised?

• Which emotional need is appropriate for this product—and which would be manipulative?

• What is the smallest interaction that could test the idea?

The distinction matters. A tax product and a music product should not manufacture the same emotion. A healthcare flow should not chase surprise where clarity and safety are needed.

Delight has to belong to the situation.

The prototype made the emotional claim testable

Frameworks are useful because they give a team language. Prototypes are useful because they reveal whether the language survives contact with a person.

A team might say its experience creates confidence. When the flow is built, we can ask where the user hesitates. A product might promise recognition. We can inspect whether personalisation feels attentive or intrusive.

The product becomes an argument about the emotion, not only the function.

This was the point of building inside the session. We did not want participants to leave with a grid of ideas and discover later that the interaction told a different story.

Three kinds of delight

One useful way to review a prototype is to separate three levels.

Low delight: the product behaves

The basics are reliable. The language is clear. The action completes. Nothing important feels harder than it should.

This level is not exciting, but a broken foundation cannot be rescued by personality.

Surface delight: the product has character

Visual craft, motion, sound, humour and small moments of surprise can make an experience memorable. These details matter when they reinforce the product’s role.

They become noise when they compete with the task.

Deep delight: the product understands the human need

The experience reduces anxiety, creates agency, helps someone feel seen or turns a difficult moment into one they can handle.

Deep delight is difficult to copy because it depends on understanding the person, not selecting an effect.

AI changes the design responsibility

Generative tools can produce many versions of an interaction. Quantity is no longer the main constraint.

The responsibility moves toward selection. Which direction is emotionally appropriate? Which one is honest? Which one still works when the novelty disappears?

This is where product, design and research become more important. AI can offer possibilities. A team needs a point of view.

It also needs evidence. If delight matters, teams should look for behaviour and language that reveal it: voluntary return, recommendation, saved effort, reduced hesitation and the words people use when they explain the product to somebody else.

Not every signal belongs in a dashboard. But every claim should be open to being wrong.

What worked in the room

The most useful combination was framework, build and review. Each prevented the others from becoming too comfortable.

• The framework stopped people from treating delight as decoration.

• The build forced emotional ideas into specific interactions.

• Peer review showed how differently the same interaction could be experienced.

• A concrete next step kept the workshop connected to the work after the room.

The workshop also reinforced something I have seen repeatedly: non-technical builders often begin with the human situation because they are not yet distracted by architecture. The right support helps them keep that advantage while learning the constraints of making the product real.

What I would add next time

I would make the review even more behavioural.

• Ask another participant to use the core flow without explanation.

• Record the moment they pause or reinterpret the promise.

• Ask what they expected to feel before the result appeared.

• Remove one surface effect and see whether the value remains.

• Name the trade-off the team made in pursuit of delight.

The goal is not to make emotion mechanical. It is to keep the team honest about whether the experience creates what it claims.

More than shipping fast

The workshop ended with working prototypes, but speed was never the final measure.

The stronger outcome was a different standard for the product. Not: can we build it? But: what should this product understand about the person, and how will we know if it does?

The event listing records the Paris workshop and its collaborators. Nesrine Changuel’s Product Delight writing develops the argument that functional value is no longer enough when teams share the same speed advantage.

If your team can build faster but needs a stronger product point of view, bring us the real opportunity. We can turn it into a working experience and test what makes it matter.