Role: Head of Product & AI | Company: David’s Bridal | Type: AI-native platform, 0-to-1 build
Planning a wedding isn’t a pain point. It’s hundreds of very different pain points, strung across several months (or years) and dozens of “stakeholders” — many of which have strong opinions and heavy emotional investment.
That distinction matters more than it sounds like it should. A single pain point can be solved by a purpose-built feature. When I started looking into this problem space, I was beyond surprised at how many of those pain points had really been ignored.
The average couple hires around 14 vendors and meets three times that many before they choose. They make dozens of major decisions with big financial commitments tied to them, and have hundreds of branching micro-decisions that follow
- “Who should we invite?”
- “What flowers do we want in our arrangements?”
- “How much should we spend on food?”
- “What should be put on our registry?”
- “What font should we use on our website?”
- “Where do we want to go for or honeymoon?”
There are about 1.9 million weddings a year in the U.S. and 90% of couples will pass through the David’s Bridal ecosystem during the planning process.
This was the foundation for Pearl Planner.
Competition?
In tech, we have a mature product discipline. Discovery is a job. Identifying a pain point and solving it is a job. There are people whose entire function is to go looking for the friction and remove it. That practice barely exists in this space. You have a handful of tech players who have been around a long time and haven’t meaningfully changed their playbook. You have retailers, vendors, and services that have existed for decades and gone largely unchanged, apart from what entertainment media has done to expectations. Nobody was systematically hunting the friction, so the friction stayed.
The other reason is that it’s genuinely hard to get permission to play here if you’re not already a player. This is an industry built on trust at the highest-stakes moment of someone’s life. You don’t walk in cold.
David’s Bridal was unusually well positioned to walk in. And when we started looking closely at what was actually happening to our customer outside of retail — outside the appointment, outside the dress — we found someone who had been broadly neglected. Everyone in the category wanted her transaction. Very few were doing anything about her year.
We could have stayed in our swim lane. The transformation was the decision not to: to help our customer with more than the dress, and more than how her wedding party looks for a few hours on one day.
Start Where She Starts
We started early in her journey, with inspiration.
Think about what actually happens when someone gets engaged. There’s the moment of joy. Then, fairly quickly, waves of anxiety start arriving as the scale of what’s ahead comes into focus — every decision she hasn’t made yet, arriving all at once.
One of the earliest pain points we found sits right there, at the very front. Not every bride comes into an engagement with a clear picture of her wedding, but plenty have been imagining it far longer than they’ve known the person they’re marrying. Either way, she runs into the same wall: putting words around a vision is hard.
This is a human problem, not a wedding problem. It is easy to see something and react — yes, I like that, no, I don’t. It is genuinely difficult to describe a visual preference in words. Same with music, with art, with food. Taste is something we recognize instantly and articulate badly.
The traditional SaaS route is to ask. Build a better questionnaire, ask her exactly what kind of wedding she’s having, and turn her answers into a profile. What brides actually told us was simpler than that: it’s easier if I just show you. That instinct is foundationally why Pinterest works.
So the first thing we built was an onboarding experience rooted in showing rather than telling — the Vision Quiz. She’s given a curated set of images and picks the ones she likes. Behind that, we analyze her selections for elements, colors, and identifiers, classify the style signals across categories — florals, dress, venue, decor — and assemble a taste palette for her wedding. She never has to name it. She just has to react to it.
A Place to Land
Then she needs somewhere to put it all down.
The dashboard exists so a bride can show up for one or two minutes and leave with something. Not a session. Not a habit loop. A minute of clarity. It’s built around three things:
- A visual reward. Her vision board, right there, so she can confirm and affirm what she’s actually working toward.
- A view of right now. What she should be working on at this moment, plus suggestions she can pull in front of her if she feels like getting something done.
- A feed that meets her where she is. Inspirational content relevant to this specific point in her planning, not a generic firehose.
It’s also the place she navigates from as the product grows underneath her. But the core idea never changed: show up, achieve something — or at least find the something — in under two minutes.
What We Had to Decide Before We Launched
For the initial launch we had to solve enough of the right problems to be genuinely valuable and clearly different from what already existed. That meant being honest about three separate questions: what core functionality we simply had to have, where we should partner to fill a gap, and what we could launch differentiated without.
Two examples of how that reasoning went:
Do we need a wedding website? Yes, we should have one. But a couple who already built their site somewhere else shouldn’t be locked out of Planner because of it.
Do we need a registry? Yes, and it should be easier to set up because they’re already in Planner. But that doesn’t mean they can’t register somewhere else and still use everything we built.
Both of those are partner-shaped problems, not identity-shaped problems. We treated them that way.
Then there’s the category of things that flow naturally out of the work itself. Most task tools treat every task the same — a Jira ticket is a Jira ticket, and only the data inside it changes. Planning a wedding doesn’t work like that. So we built task types that behave differently depending on the moment: finding the right outfit for the micro-events that stack up around the wedding, working through vendors and getting a curated list, and purpose-built tasks for specific pain points we uncovered along the way, like nailing down your wedding colors.
We soft-launched in July 2025 and went fully live that August, with a task list of nearly 200 items sequenced against a realistic timeline. Not because every couple does all 200, but because the comprehensive version was the only way to learn where couples actually start, what they skip, and which checkboxes are secretly milestones.
Building The Agent
Here’s the tension we had to design around.
To build a clear differentiator and a strong moat, we knew we had to build this in a way where the user-facing AI is actually able to offload work. A core concept to my general approach to Ai is to offload the things you hate or avoid doing so you can focus on what you are excited about and what you are best at. In the case of Pearl AI, if the bride spent the day getting stuff done and making big decisions, we don’t want her to have to open 10 different tasks to make updates. She can simply tell Pearl what moved or got done, and Pearl can do it for her. We maintain this standard with each feature to ensure the AI is always aware of the entire product, and can always help the user with the unavoidable tedious work like adding expenses, shifting dates, leaving notes, etc.
We did this knowing that this audience wasn’t especially tech-forward, and that many of them wouldn’t lean on Pearl AI. We also knew something more dangerous: if a bride did try the AI and it couldn’t help her, that was a stopping point. She wouldn’t come back to it and she probably wouldn’t tell anyone else that it was helpful or worth using.
So we ultimately made the decision to make the the app simple and delightful to usehad to be for everyone whether or not they directly used Pearl AI.That doesn’t mean they aren’t using AI inside the product, it just means they aren’t orchestrating it themselves. I’ve made the case for before: a feature doesn’t have to be labeled AI to be powered by it.
The inspiration feed and the content that shifts per screen. The context the agent carries depending on where she is. The suggestions about how it could help. The next-up task recommendations on the dashboard. Image generation and mix-and-match on the vision board canvas. Vendor recommendations. All of it is AI, and almost none of it announces itself.
It just works. It’s there when she needs it. The whole point is relevance and focus — clearing enough space that she has the headspace to think about the one thing she actually came here to do.
What Had to Be True About Pearl
For the agent itself, three things had to be true. It had to:
- deeply understand her taste
- know where she is in the planning process
- learn from its interactions with her
That third one is what turned an assistant into an architecture decision. Memory — and specifically the structure of the agent’s memory — became the foundation for the entire backend. It determined how we stored and used data across the whole application, and which elements of the app change in response to it.
Wedding planning isn’t a Q&A problem, it’s a relationship problem, which is why we went with a knowledge graph over standard retrieval. It lets the assistant trace connections rather than fetch passages — that a preference for lace suggests something bohemian, that tropical florals imply a beach. In testing it performed roughly 10x better than standard RAG at getting the right details into the right place. And as I said in VentureBeat, the reason that matters isn’t technical: a lot of these brides don’t feel like anyone is actually listening to what they want, because everyone around them has an opinion. Part of what they need is somebody to listen and remember what’s important to them.
Linear’s Agent Interaction Guidelines are the best public articulation of the other half of it — that an agent should work through the product’s existing surfaces like a teammate rather than living in a special interface, and should be legible about what it’s doing. We landed on the same principle independently, and it’s why the agent knows what screen you’re on. Nobody should have to learn prompting to plan a wedding.
Emotional Budgeting
Budget was the next major pain point we went after, and it’s the clearest example of the pattern.
The easy version is to tell someone what a wedding costs. The useful version is to help them find the space between what weddings typically cost and what matters most to them. If a couple is getting married in Tennessee with 100 guests, there’s a real framework for what that looks like based on regional data and guest count. If she already knows her budget, she sees the breakdown against it. If she doesn’t, we help her see what’s reasonable to expect and adjust from there against her actual spending power.
The mechanic underneath is the part I like. Rather than asking her to assign a chunk to every category, or hardcoding a distribution across all of them, we let her choose what she wants to spend on and how important each thing is to her. The app then adjusts the other categories automatically to make room for what matters, and flags it when that pushes her out of range — or when there’s room to spare.
We built two paths on purpose, because we found that roughly half of our users aren’t sure what their budget looks like by the time they get to us, and many have already started trying on dresses and making purchases. So there’s a path for the bride who has a budget and a breakdown and wants to track it, and a path for the bride who hasn’t finalized any of that and needs help wrapping her head around how to think about it at all.
And Pearl is budget-aware throughout — logging expenses, pulling numbers, keeping things current so she doesn’t have to.
Major Upgrades In Year 1
Pearl AI started as “helpful” and evolved into a planning super hero quickly.
We knew that at some point users would want to make bigger changes to the timeline, so we gave the agent the ability to spin up its own subagents, build a to-do list, and work through it.
If a bride says “I’m actually not doing a bachelorette party, take that milestone out,” it removes the milestone and every task inside it. If she wants to think about her planning differently — “break this milestone into two and add three tasks that aren’t in here” — it does the whole thing and reports back when it’s finished.
Alongside that, we made sure it could deep link straight to a specific task or screen, pull content in from the library through chat, and surface vendors directly in the conversation for the times she doesn’t find what she wants on a screen, or just doesn’t feel like navigating there.
Colors started as three swatches and some dress recommendations. Today it’s five curated colors, the ability to generate palettes that work with them, and the ability to apply those colors to the images on her vision board so she sees the palette in her venue instead of as chips. She can also carry her color through her entire Planner instance as a primary accent.
Vendors started as a list. Now it’s a map view based on location, built-in search, rich previews, a list curated at account provisioning off her vision and refreshable on demand, recommendations she can just ask Pearl for, and the ability to save vendors for consideration and then formally decide on one. The Vendor Hub launched recently as the single destination for all of it, and direct messaging with vendors arrives with the new vendor platform in the next few weeks.
Offers became a real ecosystem — partner discounts on the things couples are buying anyway, like travel, stationery printing, and photography.
Vera Wang Bride x Pearl is a curated variant for couture brides, with Vera’s taste built into the agent, the content recommendations, the planning cycle, and the design of the app itself.
The bridesmaid task solves one of the most reliably miserable dynamics in planning: getting feedback from your wedding party without feeling influenced by it or obligated to act on it. She collects input, sits with it privately, and makes the call she wants for her own wedding.
And some of the best work is invisible from the outside — we’ve connected data from Planner back into the store experience, so things are easier when she walks into a David’s to buy her dress, or sends her wedding party in to buy theirs.
Recognition
Google Cloud published a David’s Bridal customer story and a New Way Now video on the platform, covering the visual-first onboarding, the vendor matching, and the color work our product team built themselves with Gemini — along with the 50 to 60 style details that now reach a showroom stylist before the bride ever walks into her appointment.
Design is visual, not verbal, which is why traditional checklists fail. We use Google Cloud Vision AI to bridge that gap and give our platform the ability to read a picture and understand exactly what a bride wants. It shifts the entire experience from filling out forms to discovering a custom vision in under a minute.
Mike Bal, Head of Product and AI, David’s Bridal — in the Google Cloud case study
Pearl Planner has also been covered across industry press:
- Google Cloud — “David’s Bridal relieves wedding planning stress with Google Cloud AI”
- VentureBeat — “Retail resurrection: David’s Bridal bets its future on AI after double bankruptcy”
- Fortune — “David’s Bridal exec has a warning for every CEO obsessed with AI’s return-on-investment”
- Retail Dive — “David’s Bridal launches AI to help couples manage wedding tasks”
- Chain Store Age — “David’s Bridal launches agentic AI wedding planning tool”
- Retail TouchPoints — “David’s Bridal to Debut Dual-Sided Pearl Planner Platform”
- Digital Commerce 360 — “David’s Bridal introduces agentic wedding planner features in beta”
- The Globe and Mail — “Aisle to Algorithm” milestone coverage
Personal Growth
Retail was outside my comfort zone. Stress and planning were not. A career spent standing between what a team can build and what a business needs, plus five kids at home, turns out to be reasonably good preparation for designing around someone else’s overwhelm. I knew the shape of that feeling before I knew anything about bridal.
The things I had to get better at, in order of how much they hurt:
Planning contingencies without data. We launched into a near-vacuum. There was no behavioral history to reason from, so every early decision had to come with a branch — if this is wrong, here’s what we do instead, and here’s the instrumentation that will tell us within two sprints. Comfort with that ambiguity was the first real requirement of the job.
Going past the data to actual people. Once the data did arrive it was seductive, and it was still only half the picture. Numbers tell you what happened, not what it felt like. Staying committed to talking with real brides — and to deliberately collecting perspectives that disagreed with each other — is what kept us solving the painful thing instead of the measurable thing.
The rigor to connect features instead of accumulating them. There’s a specific moment where a roadmap has made real progress and the honest call is to stop adding and start polishing — to make the pieces feel like one product rather than a list of wins. Knowing when to make that call, and being willing to say it out loud while everyone is enjoying the shipping velocity, is harder than it sounds.
Taking mobile seriously and refusing “good enough.” The usage data made the priority obvious, and the discipline was in never treating an experience as finished. Revisit, refine, revisit again.
Investing in capability before it’s activated. The agent is the clearest example. Much of what we built into it wasn’t going to matter the week it shipped — it was going to matter the moment a user finally tried it and expected the magical thing to just work. Building for that moment before it arrives is expensive, unglamorous, and the difference between a product that feels coherent and one that feels like a demo.
A year in, that’s the thing I’d carry to any other product. The architecture decisions compound, but so do the judgment calls. Memory over retrieval means the assistant knows her by month six. A tokenized design system means a luxury variant is a theme, not a fork. Refusing to announce the AI means she trusts what it does. And refusing to stay in our swim lane is the only reason any of it exists.