Getting started as a product engineer

If you've read this far, you should have a reasonably coherent idea of what's needed to work like a product engineer – we suggest going to chapter 1 if you landed here first.

These tips are intended to help you get started on your journey. This isn't a checklist you need to complete in order, but a series of jumping off points for learning the craft of a product engineer. Start wherever you want and see where you end up.

We'll be publishing additional chapters and modules in the future. Use the form below to be alerted when we update the handbook.

1. Build a meaningful (side) project

Many of the product engineers at PostHog acquired their skills by building side projects and iterating with real users they acquired, or founding companies. It's a great way to learn how to go from 0 to 1 on a product and, since it's your project, there's no one else to hold your hand. You own everything.

We should talk about what constitutes "meaningful" here, though. For us, it means a project with real users. They don't have to be paying users, though that's a neat extra challenge to think about.

Real users means people who have signed-up or installed your product, used it, and then continued to use it for a reasonable period of time. In other words, users who you've retained and who can give you feedback on what you've built.

Meaningful does not mean:

• Something you built as a proof of concept so you could learn how to build a product from 0 to 1, or learn some new technology. This is still a perfectly valid learning activity (a great one, even), but you'll learn more about building successful products by trying to acquire users and iterating on their feedback.

• A huge, viral success with thousands of users and renown. 10, 20, or a hundred real users is enough to consider a project meaningful. So long as someone is deriving value from what you've built, and you can talk to them about why and what they need, then you're making progress.

• Founding a company (unless you really want to). You don't have to apply to Y Combinator and raise a seed round for something to be meaningful, though it's very cool if you do.

We recommend building your own project because it forces you to learn lots of other useful skills, such as talking to users, understanding onboarding flows, event schemes and analytics, monetization, and more.

2. Learn about why your company is (or isn't) successful

If you're an engineer at an existing company, take some time to understand what drives that business:

• Who is the ideal customer and why?
• What are the user personas who use the product?
• How does pricing work and why is that the pricing model?
• What are the pros and cons of other potential pricing models?
• What are some of the key metrics the business tracks?

Talk to people who know about these things. Product managers, execs, finance officers. Tell them you want to learn about the business and keep an open mind. Ask the kind of questions you might ask when applying to a company for a job.

If you think the company you work at is bad, treat this as a learning process not a "I told you so tour." Your goal is to understand why the product and business exists as it does today, not prove how smart you are.

Alternatively, research other companies. PostHog is a good place to start. We have a public company handbook and we frequently share how we work, and the choices we made and why, in our newsletter Product for Engineers.

When choosing companies to research, consider looking at ones that are different from your own – i.e. companies with a different ICP or go-to-market motion. It can be useful to compare and contrast approaches, especially if you look at companies building similar products for different audiences.

3. Support some users directly

Product engineers support customers directly, so go do that. We don't mean responding to some tickets, we mean go find a real problem someone has encountered, talk to them about it, ship a solution, and iterate on it with them.

Better yet, skip the support queue altogether and go find the users out there complaining in public, on social media, LinkedIn, Reddit, wherever your users hang out. Talk to them. Solve their problems. The more you do this, the more you'll learn how to work with customers and solve their problems in ways that spark joy.

4. Research how people are using your product

There are dozens of ways to go about this. You could set up analytics dashboards for product and features your work on, go talk to some users about how they use the product, spend an hour a day watching user sessions to see why they get stuck.

If your company has some, go talk to some data engineers and analysts about how they do this, or product managers, whomever is out there already doing this at your company. Ask them how they approach doing user research, and how to sharpen your skills here.

5. Critique products you use frequently

Pick a product you use:

• What problem does it solve?
• Who is it solving it for?
• How does it solve it?
• What would you change and why?
• How is it different from similar products?
• What do you like and dislike about it?
• What does it feel like to use?

Get into the habit of writing up notes. They don't have to be super detailed or organized, though publishing them on a personal blog or as social posts can help you build your writing muscles at the same time. It doesn't matter if no one reads them.

This exercise is all about building and refining your product sense, the less obvious and indefinable things that make a product nice to use or not. Learning the patterns that successful products lean into, and the ones that are common to less successful products.

Next chapter: Further reading for product engineers