How Indy Turned Product Delight into a Company-Wide Experience

From Concept to Practice

I am excited to have Julien Laureau, Head of Product Design at Indy, co-writing this article and sharing his own experience building Delight at Indy.

Why Delight Matters More Than Ever

Building products has never been easier. With the rapid evolution of AI,prototyping tools, no-code platforms, and faster development cycles, almost anyone can build and ship products today. But building has never been the real problem.

Over the past 15 years, I’ve worked on globally used and loved products, from Skype to Spotify, Google Meet, and Chrome. Across all these experiences, one thing became clear to me: performance, speed, and execution are essential, but they are not what truly differentiates a product. What makes a product stand out is its ability to connect with users on an emotional level.

The products we remember, the ones we come back to and recommend, are not just functional. They make us feel something. And that doesn’t happen by chance. Delight is not a random outcome, it’s an intentional design choice.

During my time as a Product Leader for Delight at Google Meet, I saw firsthand that delight is not a buzzword or a vague aspiration. It can be structured, designed, and prioritized like any other product goal. It’s what transforms a product from something people simply use into something they genuinely love.

I’ve explored this topic in depth in my book Product Delight. But this article takes a different angle. It’s about how to bring delight into reality within a team and an organization.

That’s why I’m especially excited to collaborate with Julien Laureau, Head of Product Design at Indy. Julien and his team did something both bold and unusual: they dedicated an entire week to designing for delight, bringing together product, design, and engineering around a shared ambition.

I had the opportunity to highlight this initiative during his talk at TPC, and we’re excited to share the story with you here. This article bridges the gap between concept and execution, between understanding why delight matters and learning how to actually build it in practice.

What Is Product Delight

Product delight is the combination of surprise and emotional resonance, the moments when a product goes beyond simply working and creates a meaningful feeling for the user.

To design for delight, it’s essential to understand both functional motivators (what users want to achieve) and emotional motivators (how they want to feel while doing it). Delight can take different forms. Surface delight lives in small, visible moments, micro-interactions, animations, or unexpected touches that create instant joy, relief, reassurance, etc. Deep delight, on the other hand, comes from solving a meaningful need in a way that truly resonates with users over time. While surface delight captures attention, deep delight builds lasting connection.

Why Companies Struggle to Build Delight

Delight is not only about making users feel great while using a product, it’s also a powerful business driver.

Products that create emotional connection tend to see higher retention, increased engagement, and stronger referral. Users come back not just because they need the product, but because they want to. They are more likely to recommend it, trust it, and stay loyal over time. In a world where switching costs are low, this emotional connection becomes a key lever for sustainable growth.

And yet, most companies struggle to build for delight.

Product organizations are primarily optimized for delivery, not experience. Teams focus on shipping features quickly, improving performance, and hitting short-term metrics. While these are important, they often leave little room to intentionally design how users should feel.

Emotional needs are also harder to capture. Unlike functional requirements, they are rarely documented, measured, or prioritized. Without a clear structure or shared language, delight remains an abstract concept rather than a concrete goal.

Finally, creating delight requires strong alignment across product, design, and engineering. When teams operate in silos, experiences become fragmented, making it difficult to craft cohesive and meaningful moments.

This is exactly the gap Indy decided to address, not with theory, but with action.

The Indy Context: Why a Delight Week?

Indy is a French fintech SaaS platform built for freelancers. The product covers the full financial stack: invoicing, banking, bookkeeping and tax filling. In other words, it handles some of the most anxiety-inducing tasks a self-employed person faces.

Accounting software has a reputation problem. For most freelancers, opening their finance app triggers roughly the same emotional response as entering a dentist waiting room. At Indy, we believe this doesn’t have to be the case, and yes, we’re aware that sounds slightly delusional. But our conviction is genuine: you can enjoy doing your accounting. You can even enjoy filing a tax return. That’s the revolution we’re trying to pull off.

This belief isn’t just a North Star, it’s operational. Product delight sits at the center of our design strategy, and it’s non-negotiable even at MVP stage. Every new flow has to carry at least one delight element, whether that’s a micro-interaction, a piece of copywriting, a transition, or something else entirely. The format is open, the requirement isn’t.

Over time, this approach produced real progress. But we started to notice two recurring blind spots. First, cross-cutting delight subjects, the kind that don’t naturally fall into any single squad’s scope, kept slipping through the cracks. Second, the more ambitious delight work, the kind that requires deeper thinking and tighter collaboration, rarely made it onto anyone’s roadmap. We had a system that was good at injecting small doses of delight into individual flows, but not one built for tackling the bigger, messier, more rewarding problems.

That’s where Boris, head of product of one of our Tribes, walked in. One morning, he came to find me in the open space with a simple pitch: “What if we dedicated an entire week exclusively to product delight?”. And by “we”, he meant the whole product and tech team: 72 engineers, 7 designers, 11 product managers.

My first reaction was skepticism, not excitement. My concern was straightforward: if we sprint on delight for a week, does that give everyone a convenient excuse to deprioritize it for the remaining 51 weeks? Would PMs start saying “that’s great, but we don’t have time right now. Let’s put it in next year’s Delight Week”? That felt like a real risk.

Despite my reservations, we decided to give it a shot anyway, because some questions can only be answered by shipping.

How Indy Designed the Delight Week

Once we decided to move forward, the next challenge was obvious: how do you organize 90 people to work on “delight” for a week without it turning into a glorified hackathon where everyone has fun but nothing ships? The answer was structure. Deliberate, non-negotiable structure.

One of the most deliberate design choices was breaking the standard squad structure for the week. People were encouraged to step out of their usual squads and form new, cross-functional groups. The goal was to create unexpected combinations. Mixing the teams was also a way to surface ideas that would never emerge from within the usual organizational boundaries.

We then established four operating rules with the tech management:

1. Total participation. Every PM, designer and engineer of the tech and product team was in.

2. One week, hard stop. No project could extend beyond the five days. If it couldn’t ship within the week, it was out of scope.

3. Technical discipline. Developers worked on one ticket at a time, in pairs to ensure a double technical review on every piece of code.

4. Shared ownership. Every project required a designated Tech Owner and a Product Owner, responsible for decisions and follow-through.

In hindsight, these four rules were less about controlling the week than about giving everyone the confidence to fully commit to it.

Examples of Delightful Ideas Generated

Invoice customization at a glance

For freelancers, invoices aren’t just administrative documents, they’re a direct extension of their brand. The way an invoice looks says something about who you are as a professional, and most users care deeply about getting that right. Their functional motivator is simple: customize their invoice colors to match their brand identity, and do it fast.
Indy’s invoicing module already allowed efficient color customization, but the process required making deliberate aesthetic choices: picking a primary color, finding the right combinations, making it feel coherent. Simple in theory. Paralysing in practice for anyone who doesn’t consider themselves a “visual person.” The anxiety here isn’t about the feature being hard to use, it’s about the fear of making the wrong call. For many users, staring at a color picker feels less like creative freedom and more like a test they might fail. Feeling confident in their professional image, without the stress of aesthetic decision-making: that’s the emotional motivator we wanted to address.

Lou, a designer on the team, came up with an elegantly simple solution: let users extract a color palette directly from their logo in one click. Upload your logo, and Indy automatically generates a harmonious color scheme for your invoice. No color theory required. No decisions to agonize over. Just a result that feels unmistakably yours.

The delight here operates on two levels. At first glance, it removes a genuine source of friction and replaces it with a small moment of magic. The user goes from “I hope I don’t mess this up” to “oh, that’s exactly right”, instantly. But more fundamentally, it carries a subtle message: we know you, and we’ve thought about this so you don’t have to. That kind of product empathy is what turns occasional users into loyal ones. This is Deep Delight: a feature that solves a real functional problem while simultaneously addressing the emotional state of the user, on both dimensions at once.

A personal financial retro

Being a freelancer can be a lonely experience. There’s no manager to notice when you land a great client, no team to celebrate the month where everything finally clicked. You grind through the year, and then it’s January again. At Indy, we believe that as a product that sits at the heart of our users’ professional lives, we have a legitimate role to play beyond just processing transactions, and that includes acknowledging what they’ve accomplished. The functional motivator here is straightforward: give users visibility on key financial figures. But the emotional one runs deeper: we wanted users to experience genuine pride in what they’d built over the year.

Inspired by Spotify Wrapped, Lyes, a designer on the team, built a year-end financial retrospective. The feature is deliberately simple: it surfaces the highlights of the user’s year (their best month, their biggest invoice, their most active period, etc.), presented with real care for the words and tone used to frame each result. Not a dashboard. Not a report. A moment.

The delight here is about recognition. Most immediately, it fills a genuine functional gap: several of these highlights simply aren’t visible anywhere else in the app. But the core value of this feature is emotional rather than functional: it does something that accounting software almost never does: it sees the person behind the numbers, and tells them so. That shift from “here are your figures” to “look at what you built this year” is small in execution and significant in impact. This is Surface Delight: the feature doesn’t solve a new functional problem, but it creates a memorable emotional moment that deepens the relationship between the user and the product.

A fun and useful tax calendar

For most freelancers, the accounting calendar is a permanent source of low-grade anxiety. Not because the tasks are necessarily hard, but because nobody really knows what needs to be done, or when. Miss a deadline, and the consequences can be costly. It’s also, historically, one of the primary reasons people hire a traditional accountant. It’s very convenient to simply have someone that tells you what to do before it’s too late. Underneath that functional motivator, lies a deeper emotional one: feeling in control of their situation.

At Indy, we’ve invested heavily in solving this problem. Push notifications were a first step, alerting users before deadlines crept up on them. But Candice, a designer on the team, pushed the idea further: what if users could see the full picture of their obligations at a glance, directly inside the app? The compliance calendar was born: a clear, structured view of everything a user needs to do, both within Indy and beyond. Users loved it immediately. But we felt we could go further.

The Delight Week gave us the perfect opportunity to. We kept the core functionality untouched and added a layer of personality on top: subtle animations throughout, and for the months where the user has absolutely nothing to do, playful jokes in the empty states. Small touches. Deliberately light. But they transform what could easily feel like a compliance checklist into something that occasionally makes you smile.

From a classification standpoint, the animations and jokes are pure Surface Delight: they address no functional need on their own. But they were added on top of a feature that already solves a deep, genuine problem for our users. The result is a feature that earns its place as Deep Delight: the emotional layer amplifies the functional value, rather than substituting for it.

What We Learned

Running a Delight Week with 90 people is, to put it mildly, a non-trivial exercise. Here’s what we actually learned: the good, the hard, and the things we’d do differently.

What surprised us

The single biggest surprise was the speed. We knew the week would generate ideas, but we didn’t fully anticipate how fast a motivated team could go from concept to shippable feature. Many of the most impactful improvements were delivered in less than a day of actual work. That was a genuine wake-up call: not just about what the team was capable of, but about how much we’d been underestimating the cost of not prioritizing delight during normal sprints.

The quality of the output also exceeded expectations. When developers are working on something they find meaningful and visible, the bar they hold themselves to goes up. The energy in the room during the final demo was unlike anything we’d seen in a standard product demo.

And the cultural shift was real. Damien, our VP of Tech, was convinced enough by what he saw that he officially integrated Product Delight into the technical strategy for 2026, on the same level as security or code quality. That’s not a small thing. It means delight is no longer a design team concern: it’s also an engineering pillar.

On the flip side: a week goes fast. Frustratingly fast. We ended the event with a list of ideas we hadn’t had time to tackle, which is both a good problem to have and a slightly maddening one.

What was hard

The design team carried a disproportionate preparation burden. Shaping enough well-defined subjects for 90 people to work on in a very short window before the week started was genuinely stressful. A poorly scoped subject at the start of the week tends to turn into a technical surprise by Wednesday.

We also had to stay vigilant about scope creep. Some people, and you can’t really blame them, tried to sneak roadmap items through the door dressed up as delight projects. Managing that boundary required constant attention: being firm enough to protect the spirit of the week, while staying open to subjects that might have been low on the delight scale but allowed everyone to find a meaningful way to contribute.

What we’d do differently

The main lesson is: start earlier. For the next edition, we’re going to begin shaping subjects much earlier in the year and do proper technical scoping with developers well in advance. The goal is to arrive at the week with subjects that are ready to execute, not subjects that are still being defined on Monday morning.

We’re also planning to handle smaller, more self-contained subjects autonomously on the design side, using tools like Cursor or Claude Code to ship directly via pull requests. That should free up engineering capacity for the subjects that genuinely need it.

And finally: more Deep Delight. The first edition leaned toward Surface Delight, micro-interactions, animations, small moments of joy. Those matter. But the next step is to tackle the harder, more structurally integrated problems that create a lasting emotional bond with the product. That’s where the real long-term value is.

How to Run Your Own Delight Week

Indy’s experience shows that running a Delight Week is less about creativity and more about structure and shared intent. Before the week even starts, it’s critical to align the entire team on the importance of building for emotion, what it means, why it matters, and how it translates into product decisions. This creates a common language and avoids delight being interpreted as “just polish.”

From there, running your own Delight Week is about combining this shared intent with strong structure: define a clear goal, form cross-functional teams beyond usual squads, set strict constraints (short timeframe, small scope, ship or it doesn’t count), and ensure clear ownership. Prepare relevant problem spaces in advance, especially moments where the experience feels flat or stressful, and anchor every idea in a target user emotion. Focus teams on shipping real improvements rather than concepts, and end with a shared demo moment to amplify impact.

I also like framing this week as a true ceremony, a dedicated moment where teams are encouraged to be creative, have fun, and explore. This not only fosters a stronger culture of innovation but also boosts motivation. It’s an opportunity to celebrate achievements and highlight valuable outputs; for example, at Spotify, we even introduced trophies for hackathon winners.

Done right, it becomes not just a sprint, but a powerful way to embed emotional thinking into your product culture.

If you want to go deeper into designing products people truly love, you can explore these resources. In my book Product Delight, I share the full framework, principles, and real-world examples to help you intentionally design for emotional connection. If you’re ready to apply these ideas, you can use my practical templates to identify delight opportunities and turn them into concrete product solutions. And if you prefer a more hands-on approach, my online Product Delight course walks you step by step through the process, with exercises and case studies to help you embed delight into your day-to-day product work.