One of the things I love about working at PostHog is that one of our core values is Bias for impact.
If you want to make a change to posthog.com, there's no linear process you have to follow. You don't need approval from a specific person. Anyone can see your proposed changes and merge them at anytime.
It's a great example of this core value in action.
As a designer, I want to keep the bar high for our website. (As the self-described webmaster of posthog.com, I have to continually tend to the site's design and messaging if I want to maintain the title.)
Many updates I make on the PostHog website go through some stage of wireframe or mockup. This is because I very deliberately want to craft copy, tone, layout, and design – because we believe it makes a difference.
But this desire inherently conflicts with the value, Bias for action. When less design-oriented people make changes, you can't always maintain your level of quality.
But for me, that's a worthwhile tradeoff.
When someone goes to the effort to create a pull request against the posthog.com GitHub repo, it shows they believe the change was important enough that they didn't ask someone else to do it - they took it upon themselves.
I recently discovered a change to some content on our Book a demo page that sort of threw off the layout of the page, but it was still a good change.
Our Book a demo page
I spent a long time iterating on our demo request flow. In the end, this is the page you'd react after clicking a "Book a demo" link.
This page reflected a lot of work to distill down exactly who needed demos and for what. In my eyes, it was perfectly balanced and exactly accomplished the mission.
But over time, as we grew our go-to-market team, someone eventually added a demo type and changed the page. This meant stuffing in a button in a place where I might not generally ever put a button.
The page now looks like this:
Gone was my perfectly symmetrical page, and in was a third call to action. More buttons to read, more places the eyes need to travel, more decisions for the user to make.
But it's okay, because it solved a problem.
A reflection on a favorite moment in my career
A decade ago, I co-founded a B2B SaaS company. My co-founder was the developer and I designed and some front end code.
When we added a new feature, he would throw data on a sparse page, and it was my responsibility to figure out how to present that information. I loved this delineation of roles, because we had a shared vision and allowed each other to do what we were good at.
With many companies, to make a change to your website, you have to get a lot of buy-in - and that's if you have any say at all. After you get buy-in, you might have to talk to a product manager or run it by marketing or design. PostHog is different.
I love it when my colleagues make changes to the website. Anything they change to the website has our customers interests in mind. And even better for both of us: I don't end up slowing us down.
To me, it's not the end of the world if a button looks out of place for a few weeks. If it solves a purpose, it's a good change, and that will always be more important than perfectly consistent design. Like in my startup, I'll always be here to follow behind them and polish things up afterwards.
Now if you'll excuse me, I have some buttons to redesign.