yindo/posthog.com
1
0
Fork 0
mirror of https://github.com/BillyOutlast/posthog.com.git synced 2026-02-04 03:11:21 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update who we are building for (#13307)

Browse Source 
* Update who we ar ebuilding for

* Fix typos

* Update contents/handbook/who-we-build-for.md

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* Update contents/handbook/who-we-build-for.md

Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>

* Update contents/handbook/who-we-build-for.md

Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>

* Apply suggestions from code review

Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>

* Update contents/handbook/who-we-build-for.md

Co-authored-by: Simon Fisher <simon@posthog.com>

* Update contents/handbook/who-we-build-for.md

Co-authored-by: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com>

* fix

* more fixes

* remove new products section

* Update who-we-build-for.md

* Introduce churn considerations for product personas

Added a section on churn and handling persona transitions.

* Update contents/handbook/who-we-build-for.md

Co-authored-by: Daniel Z <daniel.z@posthog.com>

---------

Co-authored-by: PostHog <hey@posthog.com>
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Raquel Smith <raquelmsmith@users.noreply.github.com>
Co-authored-by: Simon Fisher <simon@posthog.com>
Co-authored-by: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com>
Co-authored-by: Eli Kinsey <eli@ekinsey.dev>
Co-authored-by: Daniel Z <daniel.z@posthog.com>
This commit is contained in:
timgl
2025-10-27 19:19:01 +00:00
committed by GitHub
parent 94e5d095a1
commit ffac8c3747
23 changed files with 72 additions and 147 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
contents/handbook/engineering/support-hero.md
View File

@@ -61,7 +61,7 @@ There are three sources of tickets:
### Shipping features
Some tickets ask for new features. If the feature is useful for users matching [our ICP](/handbook/who-we-are-building-for), then decide whether to just build it. Otherwise, create a feature request issue in GitHub or +1 on an existing one – you can then send a link to the user, giving them a way of tracking progress. Also make sure to let the [Customer Success team](/teams/customer-success) know, since they will track feature requests for paying customers.
Some tickets ask for new features. If the feature is useful for users matching [our ICP](/handbook/who-we-build-for), then decide whether to just build it. Otherwise, create a feature request issue in GitHub or +1 on an existing one – you can then send a link to the user, giving them a way of tracking progress. Also make sure to let the [Customer Success team](/teams/customer-success) know, since they will track feature requests for paying customers.
Sometimes a feature already exists, but a user doesn't know about it or how to use it. In this case, you should either send them a link to the relevant docs page or [update the docs](/handbook/engineering/writing-docs) to make it clearer.

2
contents/handbook/growth/marketing/icp.md
View File

@@ -4,7 +4,7 @@ sidebar: Handbook
showTitle: true
---
Aligned with our Strategic [Ideal Customer Profile](/newsletter/ideal-customer-profile-framework) and [who we are building for](/handbook/who-we-are-building-for), ICP scoring helps us to focus our efforts on those customers who are likely to help us hit our growth targets quickly. This is similar, but not the same as [our lead scoring](/handbook/growth/sales/lead-scoring).
Aligned with our Strategic [Ideal Customer Profile](/newsletter/ideal-customer-profile-framework) and [who we are building for](/handbook/who-we-build-for), ICP scoring helps us to focus our efforts on those customers who are likely to help us hit our growth targets quickly. This is similar, but not the same as [our lead scoring](/handbook/growth/sales/lead-scoring).
We use [Clearbit](https://clearbit.com/) to enhance our contact information as it is created and then compute a score out of 24 in [Salesforce](https://posthog.lightning.force.com/lightning/setup/ObjectManager/Lead/FieldsAndRelationships/00NHp000018JdMZ/view) based on the following parameters:

4
contents/handbook/growth/marketing/index.md
View File

@@ -75,7 +75,7 @@ This means:
### 3. No sneaky shit
Our [ideal customers](/handbook/who-we-are-building-for) are technical and acutely aware of the tedious, clickbaity, hyperbolic marketing tactics that software companies use to try and entice them. Stop. It's patronizing to them and the marketing people creating the content.
Our [ideal customers](/handbook/who-we-build-for) are technical and acutely aware of the tedious, clickbaity, hyperbolic marketing tactics that software companies use to try and entice them. Stop. It's patronizing to them and the marketing people creating the content.
For these reasons, we:
@@ -99,7 +99,7 @@ Beyond PostHog's company [mission and strategy](/handbook/why-does-posthog-exist
- **Word of mouth mindset:** We want to build a hugely successful company driven primarily by word of mouth, rather than paid ads or PR. This means being known for quality in all things we do.
- **Helping our ideal customers be successful:** Through our docs, tutorials, [newsletter](/handbook/content/newsletter), emails, video, and beyond, we help our [ideal customers](/handbook/who-we-are-building-for) be more successful, both generally in their goals as founders and engineers, and as users of PostHog.
- **Helping our ideal customers be successful:** Through our docs, tutorials, [newsletter](/handbook/content/newsletter), emails, video, and beyond, we help our [ideal customers](/handbook/who-we-build-for) be more successful, both generally in their goals as founders and engineers, and as users of PostHog.
- **Launches:** Our team ships a lot of products and features. We need launches to break through the noise and get noticed. This helps create the momentum products need to succeed.

2
contents/handbook/growth/marketing/influencers.md
View File

@@ -18,7 +18,7 @@ Some of the influencers we sponsor include:
- You can find new influencers by looking at the creators engineers share or mention internally, searching for ones who have made relevant videos, looking at the recommendations of ones we’ve already sponsored, inbound, and [Passionfroot](https://www.passionfroot.me/).
- Their audience needs to be relevant to us, ideally targeting our [ICP](/handbook/who-we-are-building-for), but broadly engineers and founders.
- Their audience needs to be relevant to us, ideally targeting our [ICP](/handbook/who-we-build-for), but broadly engineers and founders.
- Even within this group, there are some categories to avoid like job interview prep, career growth, low-level engineering, and heavy computer science focus. Try to find web or mobile developers, product engineers, startup founders, and indiehackers instead.

2
contents/handbook/growth/marketing/open-source-sponsorship.mdx
View File

@@ -6,7 +6,7 @@ showTitle: true
We do three types of sponsorships - commercial, charitable, and open source.
Measuring attribution directly is basically impossible with sponsorship activities, so we try hard to make sure we are targeting the right channels by validating opportunities properly first. We like to make sure their target audience is in [our ICP](/handbook/who-we-are-building-for) and test with smaller amounts when possible.
Measuring attribution directly is basically impossible with sponsorship activities, so we try hard to make sure we are targeting the right channels by validating opportunities properly first. We like to make sure their target audience is in [our ICP](/handbook/who-we-build-for) and test with smaller amounts when possible.
## Commercial sponsorship

6
contents/handbook/growth/sales/how-to-do-discovery.md
View File

@@ -52,7 +52,7 @@ Discovery includes preparation. Before speaking with any new customer interested
**Examples:**
- Learn more about our [ICP](/handbook/who-we-are-building-for)
- Learn more about our [ICP](/handbook/who-we-build-for)
- Cross-reference Vitally, PostHog, Slack and Salesforce for any prior engagement or current activity/status
- Learn more about who you're speaking with via LinkedIn/X
- Visit the company's website, learn about their product, who they are marketing/selling to, language they are using. Familiarize yourself with what may be important to them
@@ -116,7 +116,7 @@ A key component of discovery is qualifying customers to ensure they are a good f
**Qualifiers:**
- They fit the [ICP](/handbook/who-we-are-building-for)
- They fit the [ICP](/handbook/who-we-build-for)
- Path to $2k/mo or $20k/year in spend
- Clear problem that PostHog can solve
- Have technical resources to assist with instrumentation of PostHog
@@ -125,7 +125,7 @@ A key component of discovery is qualifying customers to ensure they are a good f
**Disqualifiers:**
- **No path to >=$20K annual spend** - Our team looks after customers who are paying or could pay [>=$20k+/yr](/handbook/growth/sales/new-sales#leads-below-the-sales-assist-threshold-less-than-20k-arr)
- **Not in ICP** - You can gather great product insights when chatting with people in other roles, but we tend to work best with our [ICP](/handbook/who-we-are-building-for)
- **Not in ICP** - You can gather great product insights when chatting with people in other roles, but we tend to work best with our [ICP](/handbook/who-we-build-for)
- **Can't meet technical requirements** - To be successful, the customer needs to (at minimum), be able to implement PostHog via the JS/SDKs
- **Support request** - Be helpful, but if it's better suited for support, you can send them thru the available [Support](/docs/support-options) channels
- **Startup program** - For companies who qualify, we have a special program designed for [startups](/handbook/brand/startups) interested in PostHog

2
contents/handbook/growth/sales/lead-scoring.md
View File

@@ -12,7 +12,7 @@ We use [Clearbit](https://clearbit.com/) to enhance our contact information as i
- *Role* - from experience we sell best to people in an engineering, product or leadership role.
- *Country* - from experience we know that certain countries have a higher inclination to pay for software so we weight those.
> Note that we also calculate an [ICP score](/handbook/growth/marketing/icp) in Salesforce. This is more marketing aligned and designed to show us whether we are capturing [who we are building for](/handbook/who-we-are-building-for) as inbound leads.
> Note that we also calculate an [ICP score](/handbook/growth/marketing/icp) in Salesforce. This is more marketing aligned and designed to show us whether we are capturing [who we are building for](/handbook/who-we-build-for) as inbound leads.
| Metric | Value | Score |
|----------------|----------------------------------------------------------------------------------------------------------------|-------|

2
contents/handbook/growth/sales/new-sales.md
View File

@@ -6,7 +6,7 @@ showTitle: true
This is our playbook for managing inbound sales, ie. customers who have contacted the sales team directly.
We [build PostHog for product engineers](/handbook/who-we-are-building-for). While many non-technical folks use PostHog successfully every day, our inbound sales process is built with technical folks in mind. Once implemented, a customer may use PostHog for all manner of things (and we hope they do!).
We [build PostHog for product engineers](/handbook/who-we-build-for). While many non-technical folks use PostHog successfully every day, our inbound sales process is built with technical folks in mind. Once implemented, a customer may use PostHog for all manner of things (and we hope they do!).
Three other general principles to bear in mind:

2
contents/handbook/growth/sales/yc-onboarding.md
View File

@@ -6,7 +6,7 @@ showTitle: true
We want to support other YC companies using PostHog because:
- Many of these companies will quickly grow into [our ICP](/handbook/who-we-are-building-for) and we have an opportunity to get in early with them.
- Many of these companies will quickly grow into [our ICP](/handbook/who-we-build-for) and we have an opportunity to get in early with them.
- A lot of our most helpful and direct product feedback has generally come from other YC companies.
- It's nice to give back to the YC community.

2
contents/handbook/marketing/events.md
View File

@@ -8,7 +8,7 @@ showTitle: true
We’re [100% remote](/handbook/company/culture) and set up to work asynchronously–but there's a real benefit in getting together in real life. Still, we’re figuring out how to do events "the PostHog way."
For us to be involved the event has to be relevant to our [ICP](/handbook/who-we-are-building-for). We prefer not to be a small fish in a big pond, so we pass on big conferences. We [prefer pull](/handbook/growth/marketing#2-pull-dont-push) over push, so we avoid booths, badge-scanning, buying attendee lists, paying to speak, webinars, and dinners.
For us to be involved the event has to be relevant to our [ICP](/handbook/who-we-build-for). We prefer not to be a small fish in a big pond, so we pass on big conferences. We [prefer pull](/handbook/growth/marketing#2-pull-dont-push) over push, so we avoid booths, badge-scanning, buying attendee lists, paying to speak, webinars, and dinners.
The event formats we get involved in (and organize ourselves) fall into one of these:

2
contents/handbook/product/per-product-growth-reviews.md
View File

@@ -59,7 +59,7 @@ In each growth review, we usually do a couple of deep dives. Topics can be propo
- Why was churn so high last month? Can we identify any reasons?
- Where in the onboarding funnel do new users struggle?
- Can we find leading indicators that predict long-term product usage? (e.g. Facebook’s 7 friends in 10 days)
- Are there any difference between [high ICP](/handbook/who-we-are-building-for) and non ICP customers in how they use the product?
- Are there any difference between [high ICP](/handbook/who-we-build-for) and non ICP customers in how they use the product?
- Are our 10 biggest customers happy users of the product?
## In-sync or async?

122
contents/handbook/who-we-are-building-for.md
View File

@@ -1,122 +0,0 @@
---
title: Who we are building for
sidebar: Handbook
showTitle: true
---
AKA our [ideal customer profile](/newsletter/ideal-customer-profile-framework) or ICP.
We build for the highest-performing **product engineers** (full-stack engineers skewed towards the frontend) building the **most-loved products** at **high-growth startups**.
We aren't focused on other members of the product team, such as PMs, designers, and data engineers, though we are aware they are oftentimes users of PostHog as well. We expect PostHog to be usable for them, but only prioritize their feature requests when they are in service of product engineering workflows and/or have been requested by product engineers as well.
> Example: PostHog anytime from Series B to IPO
Marketing and customer success should primarily focus on this ICP, but should also develop **high-*potential* customers** – customers that are likely to later become high-growth customers (e.g. James and Tim during YC). We should be in maintenance mode for **hobbyists**, such as engineers building side projects. We want to be the first tool that technical founders add to their product.
Why? We believe that the best tech companies are increasingly engineering-led. By building for the best product engineers, we'll create a positive feedback loop of being the best product for them. This is clearly differentiated from others in the space who are focused on less technical PMs. As more leading tech companies become engineering-led and have highly technical PMs, PostHog will become the clear product leader.
## Our current ICP
| &nbsp; | High-growth startup |
| --- | --- |
| **Description** | Startups that have product-market fit and are quickly scaling up with new customers, hiring, and adding more revenue. |
| **Criteria** | - 15-500 employees<br />- $100k+/month in revenue _or_ very large number of consumer users<br />- Raised from leading investors<br />- Not yet IPO'ed |
| **Why they matter?** | - Able to efficiently monetize them<br />- Very quick sales cycle<br />- Act as key opinion leaders for earlier-stage startups/slower moving companies<br />- Strong opinions on what they need - helping us build a better product |
| **Examples** | PostHog anytime from their Series B to IPO, Supabase, 11Labs |
Each team will focus more or less on different members of the product team. This is detailed on their team pages.
## Our current Persona
We build for the power users of the **product team**
**Primary focus**
- [Product engineers](/blog/what-is-a-product-engineer)
- Technical founders
- Highly technical product managers
**Should be usable by**:
- Designers
- Less technical product managers
- Data engineers
- Marketers
## FAQs
### Why double-down on product engineers vs. making it more accessible and easy to use?
**Background**
- We have good product-market fit with engineers and an okay fit with less technical product managers.
- Most of the existing product analytics tools are built for product managers who are less technical, not engineers.
- However, the best tech companies are increasingly engineering-led, with all members of the product team being technical. We believe more companies will work like this in the future.
**Principles**
- We should double-down on the best product engineers at the best product companies.
- Going incredibly far with a specific type of user instead of placating everybody means we'll get over the threshold for "I need to tell my engineer friends about this." We only get word-of-mouth growth by doing a remarkable job for a specific kind of user, not an average one for lots of people.
- We develop a strong feedback loop: by building for the best product engineers, we'll attract more of the best product engineers and the best companies. This improves PostHog and drives more word-of-mouth growth from high authority individuals and companies.
- As more of the best companies become engineering-led and grow faster as a result, PostHog gains significant market share.
**Counterargument**
- We have good PMF with engineers and not yet with product people.
- Instead, we should make the tool simpler and more accessible to product managers, so we can better work for them and companies with product manager-led cultures.
- This could potentially help us grow faster in the short-term. However, this is less convincing for long-term growth and less clearly differentiates PostHog from existing tools.
### Who specifically should we keep in mind when building?
- We should focus on the [high-expectation customer](https://review.firstround.com/what-i-learned-from-developing-branding-for-airbnb-dropbox-and-thumbtack). "This isn’t an all encompassing persona, but rather the most discerning person within your target demographic. Most importantly, they will enjoy our product for its greatest benefit and help spread the word."
- Generally, we should build for the **best product engineers** building the **most-loved products** at **high-growth startups**.
- These kinds of users are speaking to customers, looking at data, and quickly building and shipping features. They operate collaboratively within a diverse team including designers, other PMs, marketers, and executives. We want to be loved by the sophisticated power users and still good to use for the others on the team.
- They look at what PostHog will be in the future as much as what we currently offer. They choose PostHog to avoid tool sprawl and future migrations – they're betting on us shipping more and more things that make sense for them.
- For product analytics, product managers who are technical (ex-engineers, for example) are the power users of analytics. They have the desire and the time to go significantly deeper into the data.
### What is a high-_potential_ customer and why do they matter?
- Our product is very sticky. By being the default choice at the highest potential startups we can grow with them and learn from them. Other small-stage (but less high-potential) companies index on what they use.
- High-potential startups haven’t cracked product-market fit yet, but are rapidly iterating towards it. They are founded by excellent product people that likely played key IC roles in other companies or founded a company previously, often in top accelerators.
- Compared to the individual contributor personas in high-growth startups, at high-potential startups the CTO/technical co-founder will often take more of a lead.
- We want to be the first tool that technical founders add to their product – e.g. James and Tim pivoting and exploring ideas before and during YC.
- Suggested criteria:
- Small team <20 employees
- Backed by leading accelerators or previously worked at top-tier startups/bigtech
- $0-$100k/month in revenue
### What is a hobbyist and why do they matter?
- The kind of people that build passion projects and explore new technologies drive technology decisions for their org or new startup. They are often vocal online or in their communities to promote word-of-mouth growth.
- Specifically: Hobbyists are engineers spending their nights and weekends building passion projects. Normally working solo or working with a friend – e.g. Ben White building Mealyo while he was a software engineering consultant.
- Suggested criteria:
- Side-project or very early stage commercial project
- Normally one person, three people max
- Very little funding
- Significant bonus points:
- Their day job is at an ICP
- They have a large active social media reach
- They are in major tech cities e.g. San Francisco, Austin, New York, London, Berlin, etc.
### What about marketing?
- The features should be usable by the marketing team, but we shouldn’t focus on building features specifically _for_ them. Generally, they have a different level of technical ability to our core power users, and tools in the marketing stack tend to be extremely complicated (and hacky).
- There is an exception to the rule: If a feature will make PostHog more widely adopted in a company, and will decrease the risk of the company moving to a competitor, we should build the feature. Ultimately, this is in line with our wider strategy, because the more teams in a company using the same set of product data stored in PostHog vs a second tool, the more successfully the company will operate. Anti goal: Make PostHog _harder_ to use for product engineers by supporting features for non-ICP users.

46
contents/handbook/who-we-build-for.md Normal file
View File

@@ -0,0 +1,46 @@
---
title: Who we build for
sidebar: Handbook
showTitle: true
---
We define who we build for as ICP (ie, the company) and the Persona (ie the actual person using the product).
## Our current ICP
AKA our [ideal customer profile](/newsletter/ideal-customer-profile-framework).
We build for the people building products at **high-growth startups**.
Marketing and customer success should primarily focus on this ICP, but should also develop **high-*potential* customers** – customers that are likely to later become high-growth customers (e.g. PostHog itself during YC). We should be in maintenance mode for **hobbyists**, such as engineers building side projects. We want to be the first tool that technical founders add to their product.
| &nbsp; | High-growth startup |
| --- | --- |
| **Description** | Startups that have product-market fit and are quickly scaling up with new customers, hiring, and adding more revenue. |
| **Criteria** | - 15-500 employees<br />- $100k+/month in revenue _or_ very large number of consumer users<br />- Raised from leading investors<br />- Not yet IPO'ed |
| **Why they matter?** | - Able to efficiently monetize them<br />- Very quick sales cycle<br />- Act as key opinion leaders for earlier-stage startups/slower moving companies<br />- Strong opinions on what they need - helping us build a better product |
| **Examples** | PostHog anytime from their Series B to IPO, Supabase, ElevenLabs |
## Our current Persona
Persona is the job title or role of the person actually using a product in PostHog. Each team will focus more or less on different members of the product team. This is detailed on their team pages.
As companies get bigger, the type of person that uses a product changes. As an example:
- We initially built product analytics for engineers at startups.
- As those companies get a little bit bigger, they'll hire Product Managers who will mostly use product analytics. PMs have more complicated requirements for what a product analytics tool needs to do.
- Even bigger companies often have specialized "analytics engineers." These people are the most demanding.
Each product should start with a single persona, usually an early person (preferably engineer) at a startup. Teams should make sure to build a really good product with PMF for that single persona. As the product and user-base matures, new personas will emerge as users. You only serve that new persona if you've found PMF and satisfied requirements for the initial persona.
You still need to keep your initial personas happy too, which is tricky, but important as that initial persona is how we get in first.
How do you know if you have PMF and satisfied requirements? Look at churn. If the initial persona is churning from your product, you still have work to do to retain that persona before moving onto others. If instead the product has been handed off to another persona in the org, and _they_ are churning, that's an indication that you may need to start supporting the needs of this next persona.
We've not always been successful at building products for personas other than engineers. We're now at a stage where we need to be in order to continue growing.
### Churn?
If a team does not currently support a persona, and that persona churns off of using that product, we are okay with that, as long as that doesn't cause the customer to churn off of PostHog entirely. We should try to support those personas to gracefully move off of PostHog. For example: we are okay with sales people churning off to a CRM, and we'll provide exports to export PostHog data to those systems.

4
contents/newsletter/how-we-decide-what-to-build.md
View File

@@ -40,7 +40,7 @@ At PostHog, our principles for what to build tie to [our core strategy](/handboo
3. Be the source of truth for customer and product data.
We also put a lot of weight on user feedback, especially from [our ideal customer profile (ICP)](/handbook/who-we-are-building-for). We talk to users regularly and ask them to comment on our public roadmap and vote on what they want.
We also put a lot of weight on user feedback, especially from [our ideal customer profile (ICP)](/handbook/who-we-build-for). We talk to users regularly and ask them to comment on our public roadmap and vote on what they want.
There are many other principles such as agile, lean, RICE, themes, metrics, top-down planning, weighted scoring, or following a [benevolent dictator](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). What matters is **choosing something**.
@@ -54,7 +54,7 @@ By talking directly to users and making it easy to share ad hoc feedback, we’v
![Map](https://res.cloudinary.com/dmukukwp6/image/upload/v1710055416/posthog.com/contents/images/newsletter/how-we-decide-what-to-build/map.jpeg)
The axes for this graph relate to our [ICP](/handbook/who-we-are-building-for): **product engineers** at **high-growth startups**. Everything we’ve built already is in green, while things we’re building at the moment are in blue.
The axes for this graph relate to our [ICP](/handbook/who-we-build-for): **product engineers** at **high-growth startups**. Everything we’ve built already is in green, while things we’re building at the moment are in blue.
Features towards the bottom left correlate best to our ICP, but there are outliers. We’re building web analytics, for example, because it helps us get in first and it’s easy for us to build because we’ve already built product analytics.

2
contents/newsletter/remote-working.md
View File

@@ -25,7 +25,7 @@ It doesn’t have to be this way. The best remote teams are brimming with energy
Remote work doesn't work without a strong writing culture.
Documenting by default – be it information on how to [file expenses](/handbook/people/spending-money), your [ICP](/handbook/who-we-are-building-for), or what a specific team is [working on this quarter](/teams/product-analytics) – gives everyone access to the same information, regardless of seniority or location.
Documenting by default – be it information on how to [file expenses](/handbook/people/spending-money), your [ICP](/handbook/who-we-build-for), or what a specific team is [working on this quarter](/teams/product-analytics) – gives everyone access to the same information, regardless of seniority or location.
Why does this work? Because:

2
contents/newsletter/the-companies-that-shaped-posthog.md
View File

@@ -50,7 +50,7 @@ Its ability to do this comes down to two things:
There’s room in every market for another great product with a different business strategy. For us, that is being developer-focused, open-source, and multi-product. We provide more of the tools startups need, which makes us more appealing to them.
Like HubSpot, we’ve found that inbound works well for [our ideal customer](/handbook/who-we-are-building-for), which means we put a lot of effort into our website and content. Being helpful and making setup easy for engineers leads to ever-important word-of-mouth growth.
Like HubSpot, we’ve found that inbound works well for [our ideal customer](/handbook/who-we-build-for), which means we put a lot of effort into our website and content. Being helpful and making setup easy for engineers leads to ever-important word-of-mouth growth.
## 3. Zapier: Self-serve, self-sufficient, SEO 💵

2
contents/spotlight/startup-puzzle.md
View File

@@ -57,7 +57,7 @@ As you grow, it’s important not to drift from targeting your persona or to let
“When I joined Puzzle I was very happy to hear people talking about our target persona,” says Scott. “While there were still debates about some of the finer details and who some of the buyer personas may be, it was clear that our target persona was our guiding light.”
At PostHog, we’ve solved this issue with [a public handbook](/handbook) which documents [who we are building for](/handbook/who-we-are-building-for) — but Puzzle took a different approach.
At PostHog, we’ve solved this issue with [a public handbook](/handbook) which documents [who we are building for](/handbook/who-we-build-for) — but Puzzle took a different approach.
“We reinforce who we're building for constantly," says Scott. "We bring it up in all-hands regularly, for example, and will often reference it in other meetings. Internally, we're always trying to be clear that we're building primarily for founders."

2
contents/teams/customer-success/mission.mdx
View File

@@ -1 +1 @@
Grow and retain the number of paying customers who fit our [Ideal Customer Profile](/handbook/who-we-are-building-for).
Grow and retain the number of paying customers who fit our [Ideal Customer Profile](/handbook/who-we-build-for).

2
contents/teams/sales-cs/mission.mdx
View File

@@ -1 +1 @@
Grow the number of paying customers who fit our [Ideal Customer Profile](/handbook/who-we-are-building-for).
Grow the number of paying customers who fit our [Ideal Customer Profile](/handbook/who-we-build-for).

2
contents/teams/sales-product-led/mission.mdx
View File

@@ -1 +1 @@
Grow and retain the number of paying customers who fit our [Ideal Customer Profile](/handbook/who-we-are-building-for).
Grow and retain the number of paying customers who fit our [Ideal Customer Profile](/handbook/who-we-build-for).

2
src/navs/handbook.json
View File

@@ -5,7 +5,7 @@
{ "order": "1", "name": "Why does PostHog exist?", "to": "/handbook/why-does-posthog-exist" },
{ "order": "2", "name": "How we got here", "to": "/handbook/story" },
{ "order": "3", "name": "How we get users", "to": "/handbook/how-we-get-users" },
{ "order": "4", "name": "Who we are building for", "to": "/handbook/who-we-are-building-for" },
{ "order": "4", "name": "Who we are building for", "to": "/handbook/who-we-build-for" },
{ "order": "5", "name": "How we make users happy", "to": "/handbook/making-users-happy" },
{ "order": "6", "name": "How we make money", "to": "/handbook/how-we-make-money" },
{ "order": "7", "name": "Enduringly low prices", "to": "/handbook/low-prices" },

2
src/navs/index.js
View File

@@ -444,7 +444,7 @@ export const handbookSidebar = [
},
{
name: '4. Who we are building for',
url: '/handbook/who-we-are-building-for',
url: '/handbook/who-we-build-for',
},
{
name: '5. How we make users happy',

3
vercel.json
View File

@@ -1628,7 +1628,8 @@
{
"source": "/docs/max-ai",
"destination": "/docs/posthog-ai"
}
},
{ "source": "/handbook/who-we-are-building-for", "destination": "/handbook/who-we-build-for" }
],
"headers": [
{