Workforce management isn’t just a technical problem — it’s a translation problem. Between customer pain, operational reality, and engineering constraints, product decisions live at the intersection of context and tradeoffs.
In this Q&A, David Patou shares how his background in customer success shaped his path into product management, how he thinks about prioritization in a complex domain like workforce management, and what it takes to build products that balance mathematical optimization, real-world uncertainty, and emerging AI technologies.
This conversation has been edited for brevity and clarity.
Q: You transitioned to product management from customer success. How does that early exposure to customer pain points shape the way you approach problems today?
My customer success background fundamentally changed how I prioritize product work. We're constantly flooded with feedback — everything from minor bugs to major feature requests — and figuring out what deserves attention first can be overwhelming.
What that experience gave me is the ability to identify which workflows a piece of product work actually enables and how impactful those workflows are. That's become my north star for prioritization. If a customer raises an issue but the underlying workflow isn't particularly disruptive to their business, it moves down the list. But if it unlocks real business value? It shoots to the top.
This is especially critical in workforce management because it's such a specialized industry. There's a significant translation burden between what customers need and what engineering teams need to understand to build the right solution. You have to deeply grasp all the different workflows customers are trying to accomplish and which ones matter most to their business.
Q: You've been a PM for over two years now. What still surprises you or stretches you in a good way?
What's really exciting is that success is always a moving target, especially with AI entering the picture over the last couple of years.
Early on, we were competing against legacy players — companies like Nice, Verint, and Calabrio that have been around for decades without much change. We had clear advantages: we were cloud-native, we had an amazing UX team, and we could learn from their mistakes. But fundamentally, we were all using traditional code to build products.
Now that finish line has completely shifted. With AI technology that everyone experiences in their daily lives, customers' imaginations about what's possible have totally changed. This gives us so much more room for innovation. We can say, "You may have been doing this workflow the same way for decades, but we have new technology that enables a completely different approach."
It does create prioritization challenges because you want to build the flashy, innovative thing, but there's still a core job to be done that customers need from us. The bar for success is higher, but we also have more tools at our disposal, which makes it more exciting.
Q: Schedule generation has become one of Assembled's flagship capabilities. What's been the hardest part about building it?
We have incredibly talented operations research engineers building our schedule generation capabilities, drawing on practices from other large-scale industries — things like distributing compute burden across servers, shipping optimization, and mapping optimization. They're bringing that power to workforce management.
One of the most challenging aspects of product management is realizing that the mathematically optimal solution isn’t always the right one for the customer.
We can generate a schedule, look at the data, and prove it's the absolute best possible outcome. We can get there really quickly, which is exciting. But it doesn't always appear that way to the customer.
Here's a perfect example: lunch and break placement. We look at the forecast and schedule lunches and breaks during the times when you need the fewest people online. That's mathematically optimal. But customers will often say, "There are too many people on lunch at the same time."
When we point out that's the lowest point in their forecast, they respond, "I know that's what the forecast says, but in real life, I need to be prepared for other scenarios. I need to hedge against the forecast being wrong, so I want lunches and breaks distributed more evenly."
It’s mathematically sub-optimal if you assume the forecast is always right. But the people running these teams know forecasts are imperfect, so they want schedules that hedge against uncertainty. As a PM, I have to translate between engineers thinking about mathematical optimization and customers who have a gut sense of what a schedule should look like based on real-world experience and uncertainty.
Q: You partner with engineering, support, and sales regularly. What have you learned about driving cross-functional work when problems touch multiple teams?
As a PM, you're the go-between with visibility into what customers are saying, how customer-facing teams are dealing with issues, and on the engineering side, the challenges they face and how they're approaching problems. There's definitely a peacemaker role in figuring out the most effective way to reach a solution while getting everyone on the same page.
One of the biggest lessons has been helping each team understand the best way to hand off information or work to other teams so it can be picked up and executed smoothly. This happens in all directions: What's the best way to report bugs so they get resolved quickly? What's the best way to launch features so they reach customers correctly? What's the best way to communicate priorities across the customer base?
The assumption each team makes is that whatever makes sense to them will make sense to other teams. As someone hopping between all these teams, I can tell you that's never the case.
Something obvious to a customer success manager or salesperson isn't necessarily obvious to an engineer — not because the engineer isn't smart, but because they don't have the same context about how it came up in conversation, what workflow is being accomplished, or what the expected result should be.
The inverse is also true. If an engineer has spent months building a feature, it makes perfect intuitive sense to them. But when they launch it, the customer success or sales team is seeing it for the first time. They haven't developed that intuition yet.
The challenge is making sure information that feels obvious to one team is understandable to someone encountering it for the first time. Rather than acting as the sole translator, I spend a lot of time encouraging teams to work this way together. Team-to-team empathy is crucial.
Q: How has AI changed your approach to experimentation in forecasting and scheduling?
There are really a couple of layers to this.
First, there's how people at Assembled use AI to make their own workflows quicker. We're using AI coding tools to write code faster, AI design tools to prototype and ideate more quickly, and tools like ChatGPT to build out product specs with more detail. We can iterate several times before even sharing with internal teams.
The second layer is where in the product we offer AI options to end customers. Here, there's a continuous debate: everyone's excited about AI, but for a particular workflow in Assembled, is AI actually the best technology to use? Sometimes the answer is yes, sometimes it's no, and sometimes we genuinely don't know.
That last category — where we don't know — is where experimentation becomes critical. When there are different internal points of view about whether AI or a deterministic code-based approach is better, the only way to find out is to experiment. That can be stressful when you have timelines to hit and you're not sure if your approach will work or if you'll need to start from scratch.
We try to keep experiments small. When we're uncertain about the right technology, we keep the scope really narrow so that if it fails, we fail quickly. If it succeeds, we build on it in small increments. This minimizes the risk of lost work while still letting us leverage new technologies.
For example, we use LLM-based AI in several areas of the product. But in our schedule generator — and we recently wrote a blog post about this — we determined that language-based AI isn’t the best approach for a schedule optimization problem that deals with numbers, not language.
Instead, our algorithm uses a two-step approach that combines integer linear programming for optimal search with constraint programming for constraint satisfaction. It’s still AI in the sense that it’s non-deterministic and accomplishes large optimization tasks with minimal user work, and it’s the right tool for the job.
Navigating the hype around AI while building a good product and spending the team's time wisely means having honest conversations internally. Are we trying to fit a square peg in a round hole, solving the wrong problem with the wrong technology just because it's popular? Or are we shying away from an opportunity to do something differentiated? We have to be honest about which pathway we're choosing to ultimately get to the right solution for customers.
Q: When you first heard about Assembled, you weren't sure workforce management was interesting. What changed your mind, and what would you tell someone skeptical about whether scheduling and forecasting are compelling problems?
These are genuinely huge problems. There are 3 million people in the US alone who work in support — millions more worldwide — so we're impacting something that touches countless lives. And if you include everyone who interacts with support, you're talking about hundreds of millions or even billions of people. Everyone knows about support, and workforce management is the underpinning of how it actually happens.
What makes it even more exciting at Assembled today is that we're interweaving workforce management with the end customer-facing AI experience, so we're hitting every layer of the support ecosystem.
Think about it from a user perspective. When you reach out to a company, how do you get the right answer as quickly as possible?
Sometimes the right answer is through an AI agent — we know the answer, we have high confidence, so let's just provide it. Or we know the action to take, so let's take it without wasting human time.
But we know that bots can't solve all problems. That line is changing over time, but there will always be a role for humans in support. There's no silver bullet AI agent that can accomplish absolutely everything.
And when you do get transferred to a human, the worst experience is interacting with a chatbot and then waiting two weeks to hear from someone who can actually help.
In the best cases, you interact with a bot, it can't solve your problem, and it immediately hands you over to a person — carrying all the context with it. But that only works if there's actually a person available who's qualified to solve your problem, who doesn't have to transfer you again or put you on hold.
That's where workforce management comes in. Making sure all these operations work the way they need to is what Assembled enables.
Q: Assembled has grown rapidly — more customers, more complexity, more surface area. How has that affected your work as a product manager?
It affects everything in all the ways you'd expect. Just as soon as you get comfortable with something or get good at it, the bar gets higher. The challenge becomes harder, the complexity more severe. It's perpetually escalating, so before you've even reached your first success milestone, there's a new bar — larger customers, different use cases that are more complex, and so on.
But the great news is we have larger teams and better technology at our disposal to address all of those challenges. The whole thing just gets higher stakes over time because we're dealing with larger, better, and more complicated in pretty much every direction.
That's what really keeps things interesting.
Q: For someone exploring a PM role at Assembled, what qualities would set them up to thrive?
First and foremost: curiosity. Most people don't know about workforce management, and the whole world is still new to the technologies available for building really good support experiences. Anyone showing up to be a PM at Assembled is going to do a lot of learning and needs to be comfortable being in a position of learning for a significant amount of time. You'll be consistently learning about customer needs and consistently learning about new technologies we have available to address those problems.
Second, you need a lot of energy. There are so many different dimensions we're expanding on — customer base, customer types, team size, team composition, and more. You have to have the energy to push on all those frontiers and make the absolute most of everything we have going for us.
We have a huge opportunity, but it's a competitive market, and we really have to go after it and conquer it.
Interested in building products at the intersection of customer experience, operations, and AI? Learn more about open roles at Assembled.
