Building (and keeping) a design function through acquisition

BentoBox served 14,000 restaurants with a hospitality tech stack covering websites, online ordering, marketing, and operations. I was hired as Director of Product Design with two charters that turned out to be the same charter: ship product work that meaningfully moved the business, and hold the design function together through whatever came next. What came next was Fiserv's $320M acquisition. The work below is what got built and held together through that transition.

The product had grown by acquisition and addition. Each module (websites, ordering, marketing, gift cards, reservations) had been built as its own surface, with its own information architecture, its own onboarding, and its own mental model. Restaurants were buying the platform but using one or two modules out of six. Multi-feature adoption was the leverage point because revenue per restaurant scaled with the number of modules they actually used.

The second diagnosis was about the team, not the product. People were anxious. Acquisition rumors had been in the air for months before I joined, and when they confirmed, designers started asking the questions designers always ask in those moments: what happens to me, what happens to my role, do I have a future here. The product work was important. The retention work was prerequisite to it.

Three calls shaped the leadership work.

On the cross-module problem, redesign the platform around the operator's actual workflow rather than the modules' technical boundaries. A restaurant operator does not think "now I am in the websites module, now I am in the marketing module." They think "I am updating my dinner menu, which means my website needs to update, my ordering surface needs to update, and my next email needs to go out." The redesign collapsed the modules into a workflow-first information architecture that connected the work the operator was actually trying to do.

On the team, build a career ladder that the team trusted, in writing, with clarity, before the acquisition closed. This was a huge point of stress for the team. Before me, they had never had a design leader. They were a talented, high-performing group but had no idea how recognition worked — no one had ever gotten a promotion and role expectations were not clear. People do not stay through turbulence because they like their boss. They stay because they trust the system around them. The career ladder was published internally in week six of my tenure. It was probably the highest-leverage thing I did in the role, and it does not show up in any portfolio screenshot.

On the onboarding, rebuild it from a 30-day white-glove process into a scalable self-serve experience. The acquisition was going to put BentoBox into Clover's 125,000+ merchant base. White-glove onboarding does not survive that scale. The rebuild had to ship before the deal closed.

The cross-module redesign shipped across the platform's primary surfaces, with a unified information architecture, a consistent component library, and onboarding that walked operators across modules instead of within them. The career ladder, with explicit IC and management tracks, was built and published internally before the acquisition closed. Post-acquisition, the onboarding work was rebuilt from a 30-day white-glove process into a scalable self-serve experience that could be applied across the merged customer base.

$29M in attributed revenue impact across the platform. 484% increase in multi-feature adoption across the 14,000-restaurant install base. 100% team retention through the acquisition transition, which is rare in this kind of deal and which I attribute mostly to the career framework and the fact that the team felt, correctly, that they would have a path under the new owner.

The thing I learned at BentoBox that I am still applying is that design leadership inside a company being acquired is mostly about being a steady reference point for the team while the org chart around them is changing. The design work matters. The retention work matters more, because the design work depends on the retention work. The career ladder I wrote in week six was probably the highest-leverage thing I did in the role, even though it does not show up in any screenshot. The product work shipped because the team that shipped it had a reason to stay. If I were hiring my own replacement for a role like this, the question I would ask is not "what is your design philosophy," it is "how do you keep your people through uncertainty." That is the harder skill, and the more important one.