How to build a great product delivery team

When enterprise tech companies reach hypergrowth and are scaling quickly, much of their ultimate success comes down to maintaining high net retention rates, low churn, happy customers, and the ability to systematically deliver a repeatable product.

Much of this lies in the hands of one of the most undervalued teams in the company: the product delivery team. Unfortunately, the vast majority of companies treat product delivery mostly as an afterthought and cost center (or area to throw bodies) rather than a central asset.

Whether dubbed “delivery,” “forward deployed engineers,” “customer service,” “technical account management,” or (my personal favorite) “product success,” the delivery team is the last-mile bridge between the promise of your product and actual use of your product. It is also the central node of information flow — often receiving more direct customer feedback than your Product Managers and developing a more intuitive sense of the customer value proposition than your Account Execs. It is one of the most undervalued and most critical functions in any technology company.

One of my takeaways in building both LiveRamp and Datavant was to work hard on building an incredible Product Success function — which helped us have a lean team and 150+% net retention rates during key moments of growth. Here is the playbook I developed:

1. Hire overqualified people
2. Make the charter of the team to i) delight clients, ii) find ways to create leverage, and iii) find ways to improve the product — in that order
3. Use distribution lists for visibility (including CEO visibility)
4. Watch your ratios
5. Celebrate the wins
6. Situate the team under Product Management with pods matrixed into Customer Success
7. Don’t worry about end-to-end self-service
8. Don’t hide behind support@
9. Default to escalation so that bad news travels fast
10. Obsess over automation and expanding leverage for the team

More on each lesson below.

***

Lesson 1: Hire overqualified people

At both Datavant and LiveRamp, product delivery was one of our best talent pipelines for exceptional generalists into the company.

Externally, this ‘overqualified’ talent delighted customers, connecting the dots in customer demand to advocate for product features and proactively building leverage. Clients felt like they were speaking to someone empowered, determined, and sharp to help solve their problems — and enjoyed the experience of working with us as a result.

Internally, the function served many of the benefits of a rotational program: team members left as experts on the product suite, customer evangelists, and with trust based relationships across Sales, Product, and Engineering. Several executives at Datavant & LiveRamp started in the Product Success function, as did most of the Product Management team, and even some engineers and sales reps.

And hiring exceptional talent also allowed us to keep the headcount lean — which kept us more nimble.

Lesson 2: Make the charter of the team i) delight clients, ii) find ways to create leverage, iii) find ways to improve the product — in that order.

Start with “do what it takes to delight our clients.” Defining ‘delight clients’ broadly expands the mindset from ‘answering these customer tickets’ to ‘my job is to make the system work,’ leading to parts ii) and iii) of the charter.

With this three-part charter, delivery team members are empowered (and expected) to think more broadly than their individual account lists — automating their role and advocating for product improvements.

Case in point: at both Datavant and LiveRamp, many of our “new” products would start as a feature request from a specific client, and a Delivery Lead would see it, realize the generalizability of the idea, and champion investing in it (and usually figure out some hacky way to get it delivered to the client that requested). The key is to do this for just the ideas that actually ought to be productized; so a great Delivery Lead would understand the frontier of our product, our overall strategy, and clients extremely well — and would know what to champion to PMs.

The relative priority of the responsibilities of the charter matter: when in conflict, delighting the individual customer should matter most for this function. But investing in delighting specific customers should be seen as necessary as not sufficient; most delivery functions fail to tap into the full potential of the team by narrowly defining the charter and limiting the agency of the team.

Lesson 3: Use distribution lists for visibility (including CEO visibility)

One of my all-time favorite CEO hacks is the use of customer aliases to enable rapid information sharing and radical transparency.

Take a customer called “AcmeCo”. At Datavant and LiveRamp, all communications to anyone at AcmeCo would cc an email address like acmeco@datavant.com or acmeco@liveramp.com, which was in turn a listserv for all team members (sales, customer success, delivery) watching the AcmeCo account. At face value, this enabled institutional knowledge continuity, eliminated single points of failure, and facilitated real-time cross-functional communication and problem-solving.

Perhaps more valuable is the gateway customer aliases created for me as CEO to manage by random sampling — tracking a small number of random projects to gauge how things were going in general.

Customer communications are an unadulterated microcosm of the health of the business. How are customers actually using the product? Where are the issues coming up? Aliases create a door to valuable first hand data often buried in customer service tickets.

What’s more, passively (but never secretly) watching distribution lists helped foster a culture of excellence, urgency, and visibility that ambitious doers (see #1) crave.

Lesson 4: Watch your ratios

The default on any team is to incrementally scale with people rather than enabling process or automation — everyone is too busy to automate. On Delivery teams, leanness as an operating principle is not just a cost-cutting strategy but broader cultural default towards automation.

Hiring fewer, costlier, ‘overqualified’ delivery leads necessitates that each lead carry significantly more accounts, in turn creating the cultural incentive for building leverage.

A good rule of thumb that I used here was that each person on the product success team should be able to support a ~$2M account load. Of course we were adding people to the team as the company scaled rapidly, but keeping this rough ratio in mind made automation front-and-center throughout the growth process (and kept our margins high).

Lesson 5: Celebrate the wins

Delivery jobs are inherently challenging. You’re the first point of contact when a product isn’t working, you bear the brunt of any ‘Sales selling ahead of the Product’ dynamic, and at low points you feel accountable for delighting customers without the decision-making power to always make the desired changes. You’re often the one personally ‘falling on the grenade’ for a team failure.

Especially in this function, maintaining morale becomes a core organizational strategy. Adopting a cohort model (a team of high potential talent, whose commiseration leads to deep friendships) is a strong morale boosting tactic. Feeling a sense of ownership within the company, and a path for personal growth is critical. Leadership working side-by-side in the major firefights is another tactic. But celebrating wins is the easiest critical tactic.

Given the non-obvious celebration milestones in contrast to other functions (Sales has deals, PMs have product launches, etc.), we invested in ritualizing wins.

• We made Delivery Leads visible — at all hands, hackathons, customer events, Delivery team members were chosen as speakers, judges, and facilitators.
• We elevated what otherwise might be ‘non-events’ — migrating the final customers from V2 to V3 of the software — to major team celebrations.
• Every “deal won” email sent by the sales team had a section to celebrate the delivery team.

Lesson 6: Situate the team under Product Development with pods matrixed into Customer Success

As the team grows, most companies end up putting delivery under Customer Success. I think this is usually a mistake: situating the customer service/ delivery/ implementations team under the Product team forces Product to internalize constraints on how polished the product should be, and removed from the immediate customer feedback.

The delivery team is the ‘last-mile services’ side of a SaaS business. They build last-mile integrations, manually support features that have yet to be productized, and fight bugs when the product experience doesn’t meet the product promise. The Product Leader should be forced to internalize tradeoffs: should I prioritize productizing XYZ features that the delivery team is manually providing on Q4 roadmap or focus on net new functionality? Who should I hire — another PM or another Delivery Lead, and what has to be true about the product if it needs to scale with fewer Delivery Leads?

Having deep relationships with the go-to-market team is also critical for the success of the delivery team. Creating cross-functional pods (e.g., a pod that brings together Sales, Customer Success, and Delivery for a specific customer type) enables a horizontal Delivery team to stay tightly coupled with the relevant Customer Success and Sales teams.

Lesson 7: Don’t worry about end-to-end self-service

Product teams & CEOs generally envision the perfect end-to-end self-service business, and this is great when it’s possible.

However, more often than not, end-to-end pure self-service is not the right aspiration for complex enterprise SAAS businesses: configurability (rather than pure standardization) is too important in an enterprise context to make extremely simple UIs and workflows. And the ability to nimbly add in new features strains this even further if you need to immediately roll out full self-service.

Instead of letting perfect be the enemy of the good, with limited resources, it often makes sense to create a 95% automated workflow, and then tools that give leverage to the internal team to do the last-mile delivery. For example, a great ETL wizard that makes it easy for an internal implementations team to seamlessly ingest data in the right format is often better than forcing customers to standardize their formats, or learn a complex wizard themselves.

By investing pragmatically in a mostly-automated function, you can generally build a higher-margin, more nimble, and more configurable product than investing in end-to-end automation.

Lesson 8: Don’t hide behind support@

While I’m a staunch advocate of customer aliases (see #3), sending messages from a generic support@ alias instead of a human owner dilutes customer delight and distracts from clear account ownership.

Starting from a place of delighting the customer means that any customer paying 250k+/ year has a known point of contact and, ideally, a growing trusted relationship with that contact.

Internally, a clear point of contact becomes accountable holistically for the customer’s success, getting to know the client’s needs more deeply.

A generic support@ becomes a crutch, enabling poor role clarity. Support@ too easily becomes a blackhole of follow ups and finger pointing. It’s not worth it — customer aliases (see #4) provide the benefit of organizational continuity without the dilution of accountability.

Lesson 9: Default to escalation so that bad news travels fast

Building a culture where bad news travels fast makes it safe to blamelessly raise problems and rapidly assemble the SWAT team to solve those problems.

As the team on the front lines of most customer problems, delivery teams need practiced norms around blameless escalation within and across teams.

3 of my favorite tactics here:

• Red alerts — The tactic is a redalert email listserv that flags for widespread visibility any high-risk, urgent problems (product bug, churn risk, delivery delay). While the widespread visibility shouldn’t change the ownership of getting to a quick resolution, it allowed us to more effectively mobilize a cross-functional response when needed. We had a culture where anyone could start a red alert without blame, and instigators of red alerts were publicly thanked (and conversely, I would be unhappy if I learned about a problem from a customer instead of a red alert).
• Retrospectives — simple debriefs after any project: what went well, what didn’t go well, what will we do differently next time, shared to the full business.
• Customer aliases (See above).

Lesson 10: Obsess over automation and expanding leverage for this team.

Building leverage is a consistent theme across the above principles — it’s part of the ROI of hiring ‘overqualified’ talent who automate their job, key to the three-part Delivery charter, the way to maintain high-margin ratios, and an avenue to product improvement.

I think this will be one of the most immediate areas where AI has real impact on companies: over the next few years, many tasks that Delivery Teams currently perform will become highly automated, especially non-relational tasks such as data preparation, data integration, and system configuration. For instance, building API integrations — an essential part of implementing enterprise SaaS products — is already being automated (see Fractional AI’s is work with Airbyte). Obsessing about automation has always been important for delivery teams, but it’s especially important now.

—

And of course… different companies at different stages have different needs. Using support@ may be a necessity for a B2B SaaS business serving SMBs. There have been select occasions where a product has reached a stage of maturity in its development where I’ve combined delivery and customer success teams. That said, for high-growth, enterprise SaaS businesses, this playbook is what I’ve seen work best time and again.

Many thanks to Annie Powers, who worked with me to draft this article, as well as the many exceptional product implementation leads that I’ve co-developed this playbook with over time.