Your CSM Doesn't Need to Be a TAM. Stop Enabling Them Like One.
- Alexander Martínez Kocmann
- Aug 14
- 2 min read
Here's a question most CS organisations never quite settle: how much product knowledge does a CSM actually need? Too little, and they can't hold a credible conversation. Too much, and you've built an expensive, poorly-scoped Technical Account Manager who's also expected to run 40 accounts, own renewals, and drive expansion. Most organisations don't resolve this deliberately — they let it drift, usually towards "more," on the assumption that more is always safer. It isn't.
AWS's TAM model is a useful contrast. TAMs sit inside the support organisation, are dedicated to a small number of large accounts, and carry deep, hands-on architecture and troubleshooting knowledge. They have no upsell or renewal responsibility — that trade-off is deliberate. A CSM is a different role entirely: strategic and consultative, managing a portfolio across segments, measured on renewal, expansion, and satisfaction. Expecting TAM-depth technical knowledge from someone carrying a CSM-sized book of business isn't ambition — it's a structurally unworkable ask that quietly sets people up to fail.
The answer isn't "less knowledge." It's the right kind. A CSM's product knowledge should orient around ROI, value realisation, and the business metrics a feature actually moves — not the implementation detail underneath it. They need to know what something does for the customer's business, not how it was built. That's a genuinely different curriculum to the one most enablement programmes default to, which is usually a diluted version of what Support already receives.
If your CSM product training largely mirrors Support's RUN-oriented content, that's not because it's what CSMs need — it's because nobody defined the value-oriented alternative. And if TAM-level depth genuinely is the goal, that's a legitimate choice, but it comes with a cost: real technical enablement investment and a materially smaller book of business per CSM. TAM depth and CSM scale don't come from the same headcount. Choose one, deliberately.
Where does your organisation draw this line — and was it actually drawn, or did it simply happen?
Key takeaways:
→ CSM and TAM product knowledge aren't the same skill at different depths — they serve different jobs.
→ CSM product knowledge should centre on ROI and value realisation, not architecture or implementation.
→ If CSM training mirrors Support's, that's a default, not a decision.
→ TAM-level depth is valid, but it requires investment and a smaller book of business, not just more training hours.
