Adding handbook page on how to be a curious TAM

[seanpem]

Changes

Please describe.

Add screenshots or screen recordings for visual / UI-focused changes.

Checklist

• I've read the docs and/or content style guides.
• Words are spelled using American English
• Use relative URLs for internal links
• I've checked the pages added or changed in the Vercel preview build
• If I moved a page, I added a redirect in vercel.json

[github-actions]

Deploy preview

Status	Details	Updated (UTC)
🟢 Ready	View preview	May 26, 2026 01:28PM

[github-actions]

Vale prose linter → found 6 errors, 7 warnings, 0 suggestions in your markdown

Full report → Copy the linter results into an LLM to batch-fix issues.

Linter being weird? Update the rules!

contents/handbook/growth/sales/how-to-be-a-curious-tam.md — 6 errors, 7 warnings, 0 suggestions

Line	Severity	Message	Rule
15:61	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
19:191	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
20:25	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
21:44	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
29:252	warning	Use 'PostHog' instead of 'Posthog'.	Vale.Terms
65:63	warning	'IPOs' is a possible misspelling.	PostHogBase.Spelling
67:51	warning	'Exa' is a possible misspelling.	PostHogBase.Spelling
71:211	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
73:1	warning	'Relastically' is a possible misspelling.	PostHogBase.Spelling
73:115	warning	Use 'GitHub' instead of 'Github'.	Vale.Terms
81:40	warning	Use American English. Use 'judgment' instead of 'judgement'.	PostHogBase.AmericanEnglish
83:84	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
87:5	warning	'Should I involve an FDE on this relationship?' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase

[willwearing]

personal pref but i think this should be higher. code == truth and docs are down stream of code

[landon-posthog]

I appreciate you writing this up, I think it's a great sign when folks start contributing to the handbook.

Two separate thoughts:

We try to write like we speak, and cut out unnecessary / flowery language. I think this could be tightened up significantly. (I am also bad at this / I talk bad).

This is all good content, but it largely exists in the handbook already. What this tells me is that it's not in a logical spot, because you are suggesting this page.

I think we need to do a cleanup of the sales handbook / TAM pages specifically, because I think much of this is covered.

On a separate note, I don't feel like this went into curiosity much, maybe it needs a different title (or I am dim)?

[landon-posthog]

This could probably be reframed in a single sentence. Drop anything that isn't essential and write like you are talking to me after 1.5 beers.

[landon-posthog]

I think reading the docs is good, necessary, etc... It's not (usually) sufficient to get into the level of detail customers need. the only way I've found to do that is to actually implement the product.

[sachinr]

In its current form, I think this doc is more of a basic onboarding guide. I think it has the potential to be a lot more opinionated and more focussed on curiosity in customer interactions.

Where I think you're heading with the current iteration is that having a great baseline knowledge of the product is the necessary foundation to be a curious TAM. This is because it gives you the ability to take the conversation in multiple different directions depending on the answers to your questions. Without the knowledge, you're stuck trying to push the conversation you prepped for. I think that's great and we should make it crystal clear.

I'd love to see us create a really clear framework for the types of questions to ask in a call. As an example, it could look something like this (very Command of the Message-esque):

1. What is your current state?
2. How does this impact your ability to do x?
3. What does your ideal state look like?
4. If you get to this desired state, how does that impact you?
5. What are your core requirements?
6. How will you know this rollout has been successful?

Every question gives you something that's useful in driving adoption/expansion.

Alongside specific questions you can ask (with the rationale for asking them), I think we can outline examples of what makes a good question. For me, the best questions are open-ended (Tell me about..., Explain to me..., Describe to me...).

Finally, I think that the mindset of a TAM is really important. You have to approach conversations as an opportunity to learn. If you assume you know more than your customers, you won't take the time to ask them as many questions as you should and you likely won't listen closely to their answers.