Product design process

Last updated:

|Edit this page

No product design within small teams

We encourage engineers to act like feature owners, carrying a project from ideation to completion. We maintain a design system in Storybook, so engineers can build high-quality features independently, as much as possible.

Because engineers choose their sprint tasks near the beginning of a sprint (and product doesn't plan tasks for engineers in advance), our process doesn't allow for us to have a product manager and a designer to work closely together before a task gets selected by an engineer.

In our process of short, 2-week sprints with no pre-planning, design would become a blocker to an engineer quickly iterating on a feature. Thus, engineers don't get support from product designers. Product designers should deliver high quality components. The product teams should have people in them that can ship good-enough quality interfaces using those components. If that's not true, we should hire or move people around.

Learn more about how we decide this in our guide to working with product designers, for engineers.

Requesting artwork and brand materials.

Need some custom artwork? Read the art and branding request guidelines.

Portfolio

You can find PostHog's design portfolio on Dribbble... or just have a look around!

Questions? Ask Max AI.

It's easier than reading through 631 pages of documentation

Community questions

Was this page useful?

Next article

Email comms

Our email communications can be broadly divided into broadcasts (one-off emails to specific lists, like a newsletter), campaigns (repeatable workflows which users move through dynamically), and API triggered emails (self-explanatory). This page doesn't deal with our Product for Engineers newsletter , which is sent through Substack and managed by the Content & Docs team. Email broadcasts We regularly send two email broadcasts. Changelog, a product announcement email sent every month. Sent via…

Read next article