Various corrections to spelling and punctuation. (#12063)

Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com>

contents/handbook/how-we-get-users.md

@@ -14,7 +14,7 @@ So when it comes to marketing and sales, we are optimizing for developer experie
 
 We've met a lot of successful founders in our space who are full of regret, despite leading companies with well over $100m in annual revenue! The one regret they _all_ had in common was letting go of their growth engine (people recommending their product to each other) and getting focused on sales. They all wound up exiting. That's why they told us this stuff.
 
-The way this pans out? They gradually shifted as they got bigger from building for users, to building for buyers to optimize for revenue growth. Over time, that killed their word of mouth growth, which caused them to have to work harder for each sale. So they got more salesy, and so on. They became companies that focused on making a bunch of money _by_ building a product, instead of being companies focused on building a great product.
+The way this pans out? As they got bigger, they gradually shifted from building for users toward building for buyers, hoping to optimize for revenue growth. Over time, that killed their word-of-mouth growth, which caused them to have to work harder for each sale. So they got more salesy, and so on. They became companies that focused on making a bunch of money _by_ building a product, instead of being companies focused on building a great product.
 
 We won't make this mistake.
 
@@ -22,7 +22,7 @@ We won't make this mistake.
 
 Our [Content Team](/teams/content) is small. Way, _way_ smaller than our competitors'. Winning on volume of content is out of the question. So we'd better win on quality.
 
-This constraint has worked out pretty well for us. Distribution is pretty easy when the thing you're working on is good enough to generate word of mouth growth – and this helps build an enduring developer brand.
+This constraint has worked out pretty well for us. Distribution is pretty easy when the thing you're working on is good enough to generate word-of-mouth growth – and this helps build an enduring developer brand.
 
 We even hire full-stack developers into our marketing team to make sure we can cover the full depth needed in a lot of our tutorials, docs, and posts.
 
@@ -36,11 +36,11 @@ We treat our website as a product. With real investment. When we were just a cou
 
 When we started out, we also realized that all our competitors had crappy marketing websites.
 
-And, as with so much that we do, we get an _increasing return_ on quality. If we do things noticeably better than everyone else, then we're remarkable. That results in word of mouth growth.
+And, as with so much that we do, we get an _increasing return_ on quality. If we do things noticeably better than everyone else, then we're remarkable. That results in word-of-mouth growth.
 
 ## We make it extremely easy for you to buy PostHog
 
-Most sales teams do a bunch of low quality cold outbound that harm their company's reputation and 99.999% of the time is ignored. And then once they've got you on a call, they pepper you with [MEDDPICC](https://www.getweflow.com/blog/meddpicc) questions before actually letting you see the product. Who knows, maybe 3 meetings later they'll share some pricing too!
+Most sales teams do a bunch of low-quality cold outbound that harm their company's reputation and 99.999% of the time is ignored. And then once they've got you on a call, they pepper you with [MEDDPICC](https://www.getweflow.com/blog/meddpicc) questions before actually letting you see the product. Who knows, maybe 3 meetings later they'll share some pricing too!
 
 We do things [a little bit differently](/sales). Customers _buy_ from us, we don't _sell_ to them. It means we can instead invest our money in shipping more (and better) products, at lower prices than our competitors, to provide a sustainable advantage.
 

contents/handbook/how-we-make-money.md

@@ -8,7 +8,7 @@ We make money from those that have it and like our products. We don't make money
 
 ## How we do sales is based on the best experience for our Ideal Customer Profile
 
-I cannot think of any harder group than developers to convince via a cold call or email to buy software. We should focus all our energy on inbound – that's why we don't do outbound sales.
+I cannot think of any harder group than developers to convince, via a cold-call or email, to buy software. We should focus all our energy on inbound – that's why we don't do outbound sales.
 
 All the other rules here are based on what we felt would be the best experience for an engineering customer, whilst allowing us to grow revenue in the long run.
 
@@ -30,7 +30,7 @@ These principles mean that they will spend less than they otherwise would have,
 
 ## Be the cheapest for each individual product
 
-We can make it up by selling other products to the customer over time. This way, it's always a no-brainer to pick PostHog, we get as much word of mouth growth as possible, _and_ our single product competitors can't compete since they have nowhere to go.
+We can make it up by selling other products to the customer over time. This way, it's always a no-brainer to pick PostHog, we get as much word-of-mouth growth as possible, _and_ our single product competitors can't compete since they have nowhere to go.
 
 ## Principles for dealing with big customers
 

contents/handbook/making-users-happy.md

@@ -8,9 +8,9 @@ User happiness is fundamentally important. How do we achieve this?
 
 ## Building products that people want
 
-First, someone internally will suggest an idea. Sometimes this will come from James and Tim, but it has just as frequently come from anyone else on the team.
+First, someone internally will suggest an idea. Sometimes this will come from James and Tim, but it has, just as frequently, come from anyone else on the team.
 
-If it requires a new team to build it – which it usually will – we'll start by hiring an ex-founder who is technical. We'll onboard them into the existing team that has the most overlap. This helps get them used to working with our codebase, and with the culture we look for from each team.
+If it requires a new team to build it – which it usually will – we'll start by hiring an ex-founder who is technical. We'll onboard them into the existing team that has the most overlap. This helps get them used to working with our codebase, as well as with the culture we look for from each team.
 
 That person builds the MVP, and the only goal is to figure out if anyone will use it. With some products, the MVP may have more scope if we feel especially confident. Once the new product is in a non-embarrassing state (that won't harm our brand), we add pricing to it and put it on our website. This drives more demand. At this stage, the goal is to get the product to [product-market fit](/blog/product-market-fit-game) in PostHog's platform, which means working with customers until we have five delighted, paying customers. 
 

contents/handbook/story.md

@@ -184,7 +184,7 @@ Strategy-wise, we're just leaning into our basic three principles, which we're s
 
 Revenue is in the low $10s of millions of ARR. We're very strongly default alive and will struggle to not end up profitable next year. Every time we get close to being profitable, we start speeding up hiring. 
 
-Revenue growth is fast enough and we're getting so many unprompted offers for investment (that we aren't taking) that money isn't really a meaningful constraint any more. Whilst we have a great grip on each product's individual performance, our understanding of cross sell is a little weak, so we're working on that now.
+Revenue growth is fast enough and we're getting so many unprompted offers for investment (that we aren't taking) that money isn't really a meaningful constraint anymore. Whilst we have a great grip on each product's individual performance, our understanding of cross sell is a little weak, so we're working on that now.
 
 Our marketing is getting weirder. It's more and more fun. We've commissioned a puppet, coming in January. Watch this space. Our newsletter, [Product for Engineers](/newsletter), now has 20,000 subscribers and it's growing fast.
 

contents/handbook/which-products.md

@@ -10,9 +10,9 @@ Shipping them in the right order is key to a fast return on investment from ever
 
 ## How to pick which feature within an existing product to build
 
-In the early days, you'll be shipping the main few features that your category of product has as standard. In product analytics, this would be something like (1) capturing events, (2) trends (3) funnels (4) retention and (5) person views.
+In the early days, you'll be shipping the main few features that your category of product has as standard. In product analytics, this would be something like (1) capturing events, (2) trends, (3) funnels, (4) retention, and (5) person views.
 
-Once this is done, you'll get a stream of feature requests and bug reports from users. You can't go too wrong if you listen to these and by default prioritize those that help us get in first, first. For example, with our data warehouse, we picked multi-tenant architecture because we wanted startups to be able to get started for free or very little initial cost - even though a single tenant approach would have given us an MVP faster. Sometimes, if sales are asking, you may choose to prioritize a feature for a big customer earlier, but you should never do this when you wouldn't have shipped it at some stage anyway.
+Once this is done, you'll get a stream of feature requests and bug reports from users. You can't go too wrong if you listen to these and, by default, prioritize those that help us get in first, first. For example, with our data warehouse, we picked multi-tenant architecture because we wanted startups to be able to get started for free or very little initial cost - even though a single tenant approach would have given us an MVP faster. Sometimes, if sales are asking, you may choose to prioritize a feature for a big customer earlier, but you should never do this when you wouldn't have shipped it at some stage anyway.
 
 Later on, you can then _innovate_ several ways:
 
@@ -24,18 +24,18 @@ Later on, you can then _innovate_ several ways:
 
 Products we build into the platform must:
 
-* Be a product that our ICP could use, and there already is a $1bn competitor in the market (ie a company with around $100M in revenue). This guarantees what you build will be useful.
-* Be something that you are very excited to build. People pursuing their interests get more done, go much further and execute to a better standard.
+* Be a product that our ICP could use, and there already is a $1bn competitor in the market (e.g. a company with around $100M in revenue). This guarantees that what you build will be useful.
+* Be something that you are very excited to build. People pursuing their interests get more done, go much further, and execute to a better standard.
 
 Ideally, but not necessarily, products we build should:
 
 * Help customers to build more successful products. This doesn't _just_ mean writing code, it means commercial stuff too.
-* Help us to offer all the tools in one - help us as quickly as possible cover the "major" pieces of software that every startup uses
-* Help us to get in first - some tools are adopted earlier in the customer lifecycle than others. Starting with these avoids customers moving to competitors' products then us having to migrate them over.
+* Help us to offer all the tools in one - help us to, as quickly as possible, cover the "major" pieces of software that every startup uses.
+* Help us to get in first - some tools are adopted earlier in the customer lifecycle than others. Starting with these avoids customers moving to competitors' products, then us having to migrate them over.
 * Help us to be the source of truth - some products are great at providing additional data, or working on top of the existing data PostHog stores. This means your product will probably help make multiple other products more powerful.
-* Increase our luck surface area - some products have more upside than others, for example, API access may yield surprising results compared to a super narrowly scoped new product like a cookie banner product
-* Be very easy to integrate and turn on for existing customers. For example, users can enable the product without a code change
-* Have crappy competitors - successful companies but horrible products and/or sales experience
+* Increase our luck surface area - some products have more upside than others, for example, API access may yield surprising results compared to a super narrowly scoped new product like a cookie banner product.
+* Be very easy to integrate and turn on for existing customers. For example, users can enable the product without a code change.
+* Have crappy competitors - successful companies but horrible products and/or sales experience.
 
 ![a diagram showing which products we could build in which order](https://res.cloudinary.com/dmukukwp6/image/upload/v1710055416/posthog.com/contents/images/product-order.png)
 

contents/handbook/who-we-are-building-for.md

@@ -36,15 +36,15 @@ Each team will focus more or less on different members of the product team. This
 
 - 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.
+- 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.
+- 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.
+- 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.
 
@@ -52,7 +52,7 @@ Each team will focus more or less on different members of the product team. This
 
 - 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. 
+- 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.
 
@@ -62,7 +62,7 @@ Each team will focus more or less on different members of the product team. This
 
 - 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.
+- 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.
 
 - 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.
 
@@ -70,7 +70,7 @@ Each team will focus more or less on different members of the product team. This
 
 - 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.
+- 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.
 
@@ -106,4 +106,4 @@ Each team will focus more or less on different members of the product team. This
 
 - 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.
 
-- 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 use 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.
+- 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.