Process Debt: A Conversation with Tanay Padhi
Product Leader & Founder
Tanay Padhi is a product leader and founder. Previously, he led product at Orby AI, where he built agentic process discovery tools for finance, accounting, and HR workflows. His career has been on the product side: Google APM, Found, Orby. We talked about what enterprises get wrong about their own processes, who should own discovery, and why FDE teams need to think like a revenue function.
At Orby you built an agentic process discovery product to uncover process information at enterprises. What did you learn about how enterprises actually work versus how they think they work?
It’s an age-old problem. There have been previous approaches like process mining and task mining that predate the LLM age. But with reasoning and multimodal capabilities, these models become a really big unlock.
Enterprises have so many processes through all the different layers of organisation structure. How things get done is a function of the people involved, the business model, the systems they’ve organised. And these processes always evolve over time.
At Orby, we worked with a large private company thinking of going public. For them, that meant making sure they weren’t just following their existing process, but moving towards something compliant with public markets. How they recognise revenue, how they handle discounts, rollover amounts.
A lot of this is information they have to painstakingly document. But in many cases, the only reason processes get documented is because you have a big moment like this.
What happens all the moments in between? When you add more members to a team? When the process changes for smaller reasons? That stuff never gets documented. People learn it from coworkers. By seeing and observing. Or they come up with their own ways of doing things.
You start to build up almost this debt. In the same way you have technical debt, it’s like process debt. People have figured out band-aids to solve problems that exist in their heads but don’t lend themselves to real transformation.
The key insight was: how executives and even process owners think work is happening versus how it’s actually happening often has a very big gulf between it.
Once you get to the people doing the job day to day, they show you all the edge cases. All the ways they do things that even their managers or VPs had no idea was happening.
FDEs spend a lot of time trying to understand business processes and extract business rules. What can be automated and what still needs a human?
A lot of business logic, actually the majority from a process standpoint, isn’t well documented or structured.
An example: people know that if an invoice is between $10,000 and $25,000, they probably need the finance director to review it. But if it’s above $25,000, who should review it? Is it still the director? Is it a VP? Maybe it needs an additional round of review from the controller if the GL code is of a particular category.
There are all these little details that come up.
One theory is we can look at decision traces. We can look at what decisions people made. But the reality on the ground is when people make decisions and carry out a task, they’re not documenting why they made that decision. They’re going off some knowledge in their head, or they were trained to do it but aren’t referring to that anymore.
None of these passive observation techniques answer the why question.
That’s where FDEs are critical. The role is not just to say “here’s what happened.” It’s to say “why did you do this?” Because the whole point of building an agent that can reason and take action is that it knows what to do not just in that exact scenario, but in similar ones.
One FDE leader put it well: how I know someone is really good at this role is they ask the right questions at the right times.
That’s the part FDEs will continue needing to take the lead on.
Is there also something about humans wanting to work with humans? Customers wanting to discuss things with someone rather than typing into an AI?
One thing a lot of people don’t realise is enterprises are not trying to buy software. They’re not trying to buy a seat of a certain product. They’re trying to buy outcomes. They need a problem solved in a way that delivers ROI.
Too many people approach it from the standpoint of: we give them the software and let them figure it out.
We heard recently from one of the foundation model lab companies. When they worked with their first enterprise customers, they gave them the API for a customer support use case. The customer said “great, now what next?” Both parties were looking at each other, waiting for the other to do something.
The lab was like, well, here’s the API, give it to your developers and build with it. But the customer’s expectation wasn’t an API. The expectation was: you help us solve the inefficiencies in our customer support.
That’s the mismatch even big, well-funded companies see.
With FDEs, there are two levels of what you’re selling. The first is outcomes. The FDE’s job is to make sure the outcome shows up in the form of results.
But where we can improve leverage for FDEs is when they start to own transformation rather than just outcomes. Outcomes happen at an individual workflow layer. The more we can give FDEs leverage to launch faster, they’re looking at transforming teams, organisations, entire functions.
That’s what transformation officers, COOs, CIOs are looking for. They want a thought partner who can help transform everything they run, not just deliver outcomes on particular workflows.
Who should own discovery, product or FDE?
This speaks to an existential question that many companies don’t always get to: do we see ourselves as an AI-powered services company, or do we see ourselves as a SaaS company?
For companies that present themselves as AI-powered SaaS with those investor expectations and margin pressure, the FDE’s work initially closes the gap between the product and the end customer. But ultimately the FDE’s job should be the final 20%, and the value has to come from the core product.
The way this works is if you set up a very good feedback cycle between the FDE and the core product team. It has to go in both directions.
You want to make sure the forward deployed team is always implementing the latest version of your product. We hear even at very large companies, FDEs will say they ship so quickly that sometimes they’ll show something to a customer and realise they’re implementing an obsolete version of the SDK because something shipped last week and they didn’t know.
But then on the flip side, FDEs see the truth and reality on the ground. You will always get higher signal from actual deployment than from the discovery questions a PM would normally do. Those are always hypothetical: if we built this, would you use it? Would you pay for it?
The highest signal is the customer telling the FDE: I need this feature right now because I have this workflow, I have this ROI in mind, and I need you to solve this problem for me.
If the FDE is seeing the same thing four or five times, that’s probably a failure on the core product team. They’re not building into the platform the things they’re hearing repeatedly. That’s a failure of product management.
I’ve heard people say FDEs aren’t qualified to influence product decisions. Do you think there’s a point where they overstep, or is the problem that they don’t push enough?
It’s an org structure thing. And partly culture.
The really successful companies are the ones where FDEs feel empowered to say: we are ultimately the authority on what the customer is saying and what the customer problems are. Because we are embedded. We deal with their problems day to day. We know their workflows. We know their systems.
That’s the highest signal you can get. FDEs have to feel empowered, but product teams also have to make sure they listen to those signals.
The best product managers at B2B companies also work with design partners constantly. In many regards, that’s a shallow FDE motion, just for a very small number of customers. It’s no different at scale when you build out the FDE motion.
Any team that’s not able to leverage that feedback cycle is giving up on a goldmine of data coming straight from customers.
A lot of startups are hiring one FDE and trying to use the role to find product-market fit. But companies like Palantir say FDEs are for scaling, not for finding PMF. What do you think?
With AI, even the definition of product-market fit is evolving slightly. You can build products so quickly, build solutions so quickly.
Product-market fit assumes a paradigm where you have a certain budget to build product, both in terms of time and resources. That’s why we think in terms of minimum viable product. How little do we need to build?
That paradigm has shifted. It’s never been easier and faster to build.
That’s what enables this new motion where FDEs can build a bunch of things before you have product-market fit and figure it out along the way. Earlier, a team of 20 people could only build one product with three design partners. Now a team of 20 could, in theory, build five very different solutions within a vertical.
You still want to strike that balance. But it’s a lot more possible to build faster, as long as you have some understanding of how this comes back into the product.
There are things you simply can’t productise easily. If you spend a lot of work building an integration with a specific enterprise company’s middleware that Accenture built 15 years ago, that’s one-off no matter what.
But that’s different from saying: as an insurance company, we’ve only done claims processing, but now we also want to be part of underwriting. We’ll do that with a new customer first, knowing parts of it can be reused across all customers.
Tanay recently left Orby to start a company focused on institutional knowledge for enterprise AI. I asked him what problem he kept seeing that made him want to build it.
What’s the core problem?
When working with large enterprises, they’re looking for outcomes and then one level above that: transformation of the organisation. Outcomes across multiple workflows and teams.
There’s no way to solve problems for them without being deeply embedded and being deep experts in everything that customer does and how they do their business.
How a company operates is a strategic asset. Even operational things like how they recognise revenue or structure their order forms or sales processes. This is strategic for them. The models will never be pre-trained on this.
That’s why embedded functions like FDEs will continue to exist, just like they always have for enterprise software. The total cost of ownership for enterprise systems has always been 60-70% consulting, services, management, and 30% the software license cost.
But now with all these scale-ups and startups that have FDEs, they’re raising money at SaaS multiples. The numbers they target are about one to one and a half million dollars revenue per FDE.
There are multiple ways to structure this. You work with one really big enterprise client with multiple workflows worth that much. Or every individual FDE works with 10 to 15 workflows, each worth around 100k.
In both cases, you still need to solve that fundamental institutional knowledge discovery problem. How I integrate with company A’s middleware isn’t always translatable to company B.
The motion simply doesn’t scale to support the economics without heavily automating certain aspects.
We can increase the time to value for the end customer, the time to revenue for the people who have FDEs. Through discovery, it also strategically opens up what the end goal is: now the FDE can spend more time thinking at a transformation level rather than going back into a Gong recording and looking at minute 23:40.
You mentioned 1 to 1.5 million per FDE. That’s a specific number.
Forward deployed functions are a revenue function. Even if it’s forward deployed engineering. It’s a revenue function because that’s the gap from your bookings to revenue, or your contracted revenue to actual revenue.
Making sure the margins work is essential. If you’re bottlenecked on an FDE team, that’s a direct bottleneck on your revenue.
That’s how every company with a forward deployed function should be thinking about their deployment teams.
For you as a forward deployed company, your 50th deployment has to be substantially faster, like four times faster than your 10th deployment. That’s what makes the economics work.
Tanay Padhi is a product leader and founder. Previously he led product at Orby AI, building agentic process discovery tools for enterprises.