Newsletter: How to communicate like a product engineer #10847

ivanagas · 2025-03-05T03:13:25Z

Changes

Rough-ish draft

Would love high level feedback for now:

What's good
What's bad
What's missing

Checklist

Words are spelled using American English
Titles are in sentence case
Feature names are in sentence case too
Use relative URLs for internal links

Article checklist

I've added (at least) 3-5 internal links to this new article
I've added keywords for this page to the rank tracker in Ahrefs
I've checked the preview build of the article
The date on the article is today's date
I've added this to the relevant "Tutorials and guides" docs page (if applicable)

vercel · 2025-03-05T03:13:30Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
posthog	✅ Ready (Inspect)	Visit Preview	Mar 12, 2025 5:36pm

andyvan-ph

What's good?

I like the focus on user-centric comms right at the start. We could probably go harder on that point.
I like the framing of we're sharing how we work and how it's not about frameworks etc. All the core points are good, though I think it's a little thin on specifics in some places – see inline comments.

What's bad?

Not so much bad, but I wonder if a Dos and Don'ts-style format might give this a bit more edge?

Atm, it's mostly about about what you should do and it's all pretty uncontroversial, but often the things we don't like / you should avoid are more interesting.

Like, this line really slaps:

"The opposite of this is just saying “this isn’t working” or “what do you think of this?” Low context communication like this puts all of the work onto the receiver, leaves more room for ambiguity, and is simply less effective.

But it's relegated to a footnote to the section.

The closest example of what I mean is one Charles did ages ago, where we did it with alternating truths and myths.

Would something like this but it's Dos and Don'ts work?

(Mental note: that's a good article we could update for the newsletter!)

Alternatively, maybe the format could "Avoid XYZ" where XYZ is a common bad communication habit, then we outline "Do this instead"?

What's missing?

An ending, but I assume that's because it's a draft.

andyvan-ph · 2025-03-06T16:43:16Z

contents/newsletter/how-to-communicate.md

+- One change needing a review
+- One general team announcement
+
+This focus on information from users really sets product engineers apart from more traditional software engineering teams.


I feel like I need more here. The graphic alone is very dense, it's hard to grok your meaning without doing a lot of work. A summary would help.

andyvan-ph · 2025-03-06T16:51:18Z

contents/newsletter/how-to-communicate.md

+
+1. **All hands.** Where the most important updates are shared with the team. Q&A with James and Tim. Demos of what anyone built in the last week.
+
+2. **Sprint planning.** A [bi-weekly review](https://github.com/PostHog/posthog/issues/28840) combination of retrospective and planning done by each team. 


bi-weekly as in every two weeks, I assume? I always get confused by this.

andyvan-ph · 2025-03-06T16:51:51Z

contents/newsletter/how-to-communicate.md

+1. **All hands.** Where the most important updates are shared with the team. Q&A with James and Tim. Demos of what anyone built in the last week.
+
+2. **Sprint planning.** A [bi-weekly review](https://github.com/PostHog/posthog/issues/28840) combination of retrospective and planning done by each team. 
+
+3. **Daily huddles.** Within small teams, each member shares what they did yesterday, what you’re doing today, and gets any support they need.
+
+4. **Request for comments.** A large document related to a big decision that shares a problem, a potential solution, and gathers feedback. This is how we coordinate big problems across teams.
+
+5. **Incidents.** When something bad and unexpected happens, anyone can start an incident where a channel is created, the problem is identified, and the team works towards a solution.


I think I'd like a little more detail on all of these. Maybe expand this section?

ivanagas · 2025-03-11T20:27:42Z

Alright updated to "Communication mistakes for engineers to avoid" to try to give it a bit more ZING + addressed your points

Still haven't figured out the conclusion though...

daniloc · 2025-03-12T00:37:38Z

A thought on concluding:

if the headline frame is "here's what you're avoiding" then the conclusion could be framed affirmatively: here's what you become for avoiding such things.

Clear the table – things to avoid – then set the table with a picture of what you become?

andyvan-ph · 2025-03-12T17:59:51Z

Some more random thoughts:

I feel like we could do with some really useful / good tips on written communication. Currently this has lots of good principles, but I'm not sure what someone would takeaway and say "I'll try doing this". Lior did this well in the issue about feedback: https://newsletter.posthog.com/p/why-you-suck-at-giving-feedback
As an example, could we pull together some hypothetical or real examples of "here's some bad communication" and "here's a better version" that contains the same information, but organized in a better way with all the context etc. someone would need to take action.
I'm always a bit suspicious of articles with 5 points. What other things could we highlight here? Random ideas:
- Not being opinionated... I think there's something in this about how non-opinionated comms creates inertia. Can talking about "strong opinions, weakly held" here.
- Lack of honesty about feelings... if something is bugging you, you should get it out rather than holding onto it
- Not communicating urgency... e.g. I need this right now vs not so urgent but still important, etc.

andyvan-ph · 2025-03-12T17:30:47Z

contents/newsletter/how-to-communicate.md

+
+2. **It's backed by a user experience.** We build features because users want them and their specific needs often guide our implementation. The experiences of users are often our best guide when we're deciding what to work on or how to implement it.
+
+![Facts](https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_03_11_at_10_43_31_2x_9726c09b98.png)


this meme feels a bit too intense / obscure to me

andyvan-ph · 2025-03-12T17:33:30Z

contents/newsletter/how-to-communicate.md

+
+To give you a sense of what this actually looks like, a snapshot of the last 10 Slack messages in our `#team-product-analytics` channel include:
+
+- Two bugs from support


maybe we could elevate this a bit by showing this as a pie chart? could even a bit of an analysis of week of messages to break them down?

outcome would be a breakdown of percentage for types of comms, and how much of them were about customers.

andyvan-ph · 2025-03-12T17:34:39Z

contents/newsletter/how-to-communicate.md

+
+## 2. Hiding communication in private
+
+There is an old way of thinking that if you keep knowledge to yourself, you'll have more power. In well-functioning organizations, this doesn't work. It leads to silos and confusion. You don't need to hoard information, you're not a squirrel.


could be more explicit here and add some examples of how people do this, both deliberately and accidentally.

andyvan-ph · 2025-03-12T17:37:48Z

contents/newsletter/how-to-communicate.md

+1. **Data.** Messages often include the link to the query, insight, dashboard, or error trace. Say what metric you care about.
+
+2. **Feedback.** A common sentence we see at PostHog is “X gave feedback that…” followed by a potential solution for that feedback.
+
+3. **Experience.** We care about what the end user experience actually is. Examples and anecdotes from users are hugely valuable.


this feels like one point that would really benefit from examples – e.g. one good and one bad example perhaps?

andyvan-ph · 2025-03-12T17:41:11Z

contents/newsletter/how-to-communicate.md

+
+This gives our communication further bang for its buck. It has helped us build a brand and trust with our users.
+
+We realize this brand of external openness doesn't work for everyone, but that doesn't mean you need to hide information. Companies like Palantir, Pixar, and Apple are all secretive externally, but have internal openness. This has helped them build the massively successful companies they are today.


would like to hear more about these examples if possible. how do openness internally?

how to communicate newsletter

039703c

ivanagas requested review from daniloc and andyvan-ph March 5, 2025 03:13

vercel bot deployed to Preview March 5, 2025 03:26 View deployment

andyvan-ph reviewed Mar 6, 2025

View reviewed changes

Communication mistakes for engineers to avoid

f7c6df2

ivanagas requested a review from andyvan-ph March 11, 2025 20:26

vercel bot deployed to Preview March 11, 2025 20:37 View deployment

add a conclusion

2428727

vercel bot deployed to Preview March 12, 2025 17:36 View deployment

andyvan-ph reviewed Mar 12, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Newsletter: How to communicate like a product engineer #10847

Newsletter: How to communicate like a product engineer #10847

ivanagas commented Mar 5, 2025

vercel bot commented Mar 5, 2025 •

edited

Loading

andyvan-ph left a comment •

edited

Loading

andyvan-ph Mar 6, 2025

andyvan-ph Mar 6, 2025

andyvan-ph Mar 6, 2025

ivanagas commented Mar 11, 2025

daniloc commented Mar 12, 2025

andyvan-ph commented Mar 12, 2025

andyvan-ph Mar 12, 2025

andyvan-ph Mar 12, 2025

andyvan-ph Mar 12, 2025

andyvan-ph Mar 12, 2025

andyvan-ph Mar 12, 2025


		1. All hands. Where the most important updates are shared with the team. Q&A with James and Tim. Demos of what anyone built in the last week.

		2. Sprint planning. A [bi-weekly review](https://github.com/PostHog/posthog/issues/28840) combination of retrospective and planning done by each team.


		2. It's backed by a user experience. We build features because users want them and their specific needs often guide our implementation. The experiences of users are often our best guide when we're deciding what to work on or how to implement it.

		![Facts](https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_03_11_at_10_43_31_2x_9726c09b98.png)


		To give you a sense of what this actually looks like, a snapshot of the last 10 Slack messages in our `#team-product-analytics` channel include:

		- Two bugs from support


		## 2. Hiding communication in private

		There is an old way of thinking that if you keep knowledge to yourself, you'll have more power. In well-functioning organizations, this doesn't work. It leads to silos and confusion. You don't need to hoard information, you're not a squirrel.


		This gives our communication further bang for its buck. It has helped us build a brand and trust with our users.

		We realize this brand of external openness doesn't work for everyone, but that doesn't mean you need to hide information. Companies like Palantir, Pixar, and Apple are all secretive externally, but have internal openness. This has helped them build the massively successful companies they are today.

Newsletter: How to communicate like a product engineer #10847

Are you sure you want to change the base?

Newsletter: How to communicate like a product engineer #10847

Conversation

ivanagas commented Mar 5, 2025

Changes

Checklist

Article checklist

vercel bot commented Mar 5, 2025 • edited Loading

andyvan-ph left a comment • edited Loading

Choose a reason for hiding this comment

What's good?

What's bad?

What's missing?

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivanagas commented Mar 11, 2025

daniloc commented Mar 12, 2025

andyvan-ph commented Mar 12, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vercel bot commented Mar 5, 2025 •

edited

Loading

andyvan-ph left a comment •

edited

Loading