Update homepage hero messaging

[corywatilo]

Visually not quite done yet, but concept for a new homepage hero:

Positioning

• Product analytics → ProductOps
• De-emphasizes self-hosting to coincide with the new push on Cloud
• Calls out all main benefits (top features + data stack)

Design

• Hogs (WIP) would be tied to the hero carousel, and the currently-selected hog would be emphasized. (Hogs are currently only outlined but will be filled in when finished.)
• Active hero carousel item would be slightly zoomed (compared to other slides) and ideally each focused item would be a short animation, showing a user interacting with the product

Navigation

• Product (would feature links for Tools, Data stack, and Customer stories) Edit: + Pricing
• Docs (+ new dropdown at some point, API)
• Learn (Tutorials, User guides, Build an app, API)
• Community (Contributors, Questions?, Contribute, Roadmap, GitHub, Slack, PostHog FM, Merch)
• Company (Blog, Our Story, Team, Handbook, Investors, Careers)
• Login (Community, Access PostHog Cloud)

[andyvan-ph]

This looks interesting. I like the carousel / filmstrip setup – I think it would make it really easy to quickly gauge what we're about and our capabilities, and it's always great to actually see the product straightaway. Love that.

The Product Ops framing is a new one on me. I'm not privvy to any conversations that have happened around this, assuming there have been any, but if this is something we're doing I'd like to understand what, when, why etc. It's a big change that impacts a lot of what we're doing elsewhere, obviously.

I have lots of opinions on the nav:

• Instead of Product, I'd advocate for a 'Why PostHog' dropdown menu similar in approach to Mixpanel's. Their's is particularly good, I think, at communicating what they're about and I'm always drawn to these sections on other company's homepages.

• As a user, I'm unsure what to expect from the 'Learn' section here. Am I learning more about product features, how to use PostHog, or just 'learning' in a broad sense? I take it from your summary we'd be moving the user guides out of the docs into this section, or am I reading that incorrectly? It feels like very prominent positioning for something relatively low value / ambigious.

• Where is Try PostHog going? Straight to the Cloud sign-up page, or to the pricing page?

• After the Login link, 'Pricing' is the most clicked on thing on our current homepage nav by a long way, so it feels like something we should keep, especially given our focus on transparent pricing.

• For context on the above, these are clicks on homepage nav items in the last 7 days:

  • Login: 1.23k
  • Pricing: 513
  • Product: 219
  • Docs: 111
  • Get Started: 50
  • Company: 32
  • Blog: 31
  • Customers 19

• Would this top level nav be homepage exclusive or sitewide?

[corywatilo]

ProductOps

Gitlab has claimed the nav DevOps, and we are the ops platform of product and data. We hereby stake this claim before anyone else does! =]

Why PostHog?

Not entirely opposed - my only gut thought is Product is pretty standard, and _Why PostHog?" could be slightly more ambiguous and marginally increase cognitive load, but I could be reaching here.

"Learn"

I agree Learn could be unclear. I think I had Resources at one point, and that would probably work better. I do think it's worth splitting technical/implementation docs from product docs.

Try PostHog

We can experiment with the CTA label, but basically the same destination as what we have today - no change yet

Nav would be site-wide, but logo would be added on non-homepage.

[joethreepwood]

The Product Ops framing is a new one on me. I'm not privvy to any conversations that have happened around this, assuming there have been any, but if this is something we're doing I'd like to understand what, when, why etc. It's a big change that impacts a lot of what we're doing elsewhere, obviously.

+1

Maybe it would help to know why we're changing and what we'd want to achieve, if it's a definite direction that's been set. Ideally, any significant change in positioning should coordinate with activities on the marketing side so that the position/message is consistent.

It's also worth bearing in mind that product ops is already a role in some product teams, and by targeting that we may risk moving further from the engineers we typically do best by speaking to?

[andyvan-ph]

Gitlab has claimed the nav DevOps, and we are the ops platform of product and data. We hereby stake this claim before anyone else does! =]

I'd be interested in other opinions, but my feeling is Product Ops is a job, not a product, and I'm not sure what makes us / would make us a product ops solution.

Not entirely opposed - my only gut thought is Product is pretty standard, and _Why PostHog?" could be slightly more ambiguous and marginally increase cognitive load, but I could be reaching here.

Yeah, it's subtle difference. A few things I like about 'Why Posthog?'

1. It changes the way we communicate. 'Why?' is a more powerful, persuasive question than 'what?'

2. I feel like we're increasingly a platform of products, rather than one single product – even if it's still sold as one atm.

3. Asking 'Why?' puts visitors in a different mindset. As a user, I'm not just learning about "the product", I'm actively considering the merit of the arguments being presented.

4. Ultimately, this is the question every visitor has in their head when they visit the homepage, so having a section that basically says "this will answer your question" is super powerful

I agree Learn could be unclear. I think I had Resources at one point, and that would probably work better. I do think it's worth splitting technical/implementation docs from product docs.

My gut says we'd probably be better off ditching Learn and Community and putting everything under one section, maybe called Help or Support. In my head, I view Tutorials and Questions as one and the same. They're databases of solutions, whether it's how to fix an ingestion problem or how to do things in PostHog, they're all just solutions at the end of the day, so it makes sense to have them in the same place.

Also, the cynical side of me feels like having Community in the nav will be a turn off for some potential customers.

Your Resources suggestion might be the best compromise, tbh.

We can experiment with the CTA label, but basically the same destination as what we have today - no change yet

Sounds good. To be clear, the CTA is fine by me, but I strongly think we should have that AND Pricing in the top nav. Our transparent pricing is major selling point, so it's a great way to delight people when they click on pricing and actually get the answer they're looking for... as opposed to the Amplitude approach, where the 'Pricing' page contains no actual prices.

[jamesefhawkins]

Things I feel strongly about in some way shape or form.

Why PostHog?

I am opposed to this (although appreciate an unusual suggestion) - I think it is less clear than simply saying what it is.

my feeling is Product Ops is a job, not a product

This is true, simply as no one has yet built something broad enough to cover this:

I suggested this positioning but do share the concern that it could land badly with engineers (although it does describe us particularly well in my opinion at least) - I've asked @camerondeleone and @simfish85 to use it on some demo calls so we can get some feedback from customers. We can quickly iterate it if it's causing confusion (calls go weird, or we kill our conversion rates - I'd suggest @corywatilo we make this a PostHog experiment, just to monitor this as it's a big move).

After the Login link, 'Pricing' is the most clicked on thing on our current homepage nav by a long way, so it feels like something we should keep, especially given our focus on transparent pricing.

I agree strongly with this (realistically everyone wants to know this info, and we do it in a way that converts and brings differentiation) - I'd be really nervous about removing it.

I do think it's worth splitting technical/implementation docs from product docs.

Agree strongly with this. Anecdotal, but I know lots of developers who are like 'what does it do, what does it cost, where are the docs so I can look in more detail'

[joethreepwood]

I'd suggest @corywatilo we make this a PostHog experiment, just to monitor this as it's a big move).

I'd ask that we communicate progress here as clearly and early as possible. Some things we can iterate on fast, but some activities (such as SEO, sponsorship planning) are longer tail. Overall marketing tactics should also change if we're redefining ourselves, creating a new product category and educating users about it.

I'd love to know the feedback from calls on this too, before we launch an experiment. Positioning, like branding, accrues value over time through consistency so I feel strongly we should have as much information and clarity as possible beforehand.

[corywatilo]

I broke out the nav menus/dropdowns into a separate issue.

[corywatilo]

Here's a drastically improved 3-screen Figma prototype:

• Slide: Product analytics
• Slide: Session recording
• Dropdown menu: Product

Updates:

• Cleans up visuals
• Incorporates new hog art (for each feature) from @lottiecoxon
• Uses new nav menu, dropdown UI (as seen at link in previous comment) and creates first dropdown hifi

Note: These mocks are intentionally designed on a tight screen. For most of us, everything will have more breathing room.

[joethreepwood]

Design wise, it all looks good to me. But this:

is sublime.

[jamesefhawkins]

Really like the new design. Strongly enough not to just use emojis.

[charlescook-ph]

This is nice, beautifully done team!

Only two things I have an opinion on:

• ProductOps - agree it's worth trying this positioning out. This is the kind of brand bet where in 5 years time we could think 'wow glad we owned that, it's completely differentiated us from Amplitude etc.', or in 5 weeks we'll be saying 'oops that was a confusing mistake'. But we won't know if we don't make a bet.
• @lottiecoxon I'd remove the word 'Data' from the data warehouse graphic, it's not needed and a bit weird to have just one graphic randomly have a word in it. Love the rest of them though.

[corywatilo]

Figma updates:

• We now have slides for all features
• Content feels complete (enough) to run with
• Made a cool active state for icons

[marcushyett-ph]

Flyby feedback from me, as a (fairly) experienced PM, I've never really heard of the term ProductOps before and don't imagine it would resonate with our engineering focussed audience.

The term ProductOps (from the outside) sounds like a role or a department at a big company, rather than something an engineer would understand they need to enable them build better products.

The design looks great and the focus on the multiple tools in one platform value prop makes a lot of sense for us to test out in the current climate.

[corywatilo]

I initially liked ProductOps since GitLab went with The One DevOps Platform. But I wonder if there is too much of an assumption people will read it like that. After all, GitLab didn't event the term "dev ops". We would be trying to invent the term "ProductOps".

Another phrase we've had floating around is "The Product OS" - which I really liked then, and I think I might like even more now. I also think it lends nicely to PostHog being the platform you can build product + engineering aps on.

I paired this theme with a new subtitle in this carefully-worded mock:

[simfish85]

Another phrase we've had floating around is "The Product OS" - which I really liked then, and I think I might like even more now. I also think it lends nicely to PostHog being the platform you can build product + engineering aps on.

I think OS is even more new-category-defining than ProductOps was - if we are a platform you can build product + engineering apps on then we should just call ourselves a Product Platform - does what it says on the tin and people will get it.

[marcushyett-ph]

+1 to @simfish85

[andyvan-ph]

The open source Product Platform (not sure the correct capping would be here)
All the tools you need.
With the modern data stack you want

That works.

[marcushyett-ph]

I would advocate for being a little more explicit with some of these sentences since people will have different interpretations of what a product platform might be (e.g. I think JIRA when I hear Product Platform, not hotjar)

Perhaps extending: All the tools you need
to be: All the tools you need to understand your users
or something else that anchors the sentence in what the tools are needed for.

[posthog-contributions-bot]

This issue has 2042 words at 18 comments. Issues this long are hard to read or contribute to, and tend to take very long to reach a conclusion. Instead, why not:

1. Write some code and submit a pull request! Code wins arguments
2. Have a sync meeting to reach a conclusion
3. Create a Request for Comments and submit a PR with it to the meta repo or product internal repo

Is this issue intended to be sprawling? Consider adding label epic or sprint to indicate this.

[charlescook-ph]

Product Insight Platform? Product Insight Suite?

(I feel like product insight to me brings together a bunch of tools across things like analytics, recording, qualitative feedback, error logging etc.)

[simfish85]

Product Optimization Platform?

[jamesefhawkins]

Product Insight Platform

This sounds too "read only" to me. Ie feature flags have nothing to do with insight - they're all about action.

Product optimization platform

This is pretty similar to amplitude's old messaging "digital optimization system" if I recall correctly. Not a reason to not go with it, but it lacks boldness is my personal opinion

[jamesefhawkins]

The above has changed my mind - let's not do product ops.

I think product OS is a little stronger (but I'm also fine w/ product platform) - it's more engineering-oriented, and we help people operate their product, but we don't yet, and not for a while, let users build it all on top of us - with I think a broader "product platform" infers too strongly for our current state.

[simfish85]

Agree that Product OS sounds engineeringy however those engineers may also say 'You're not an Operating System' - as that's a very specific category of computing technology which we are not and has been established for decades; and I don't believe describes our desired future state either. Product (Data?) Platform describes what we do now as well as what we want to become, although it is less edgy/category defining.

[corywatilo]

You're not an Operating System

Yes buuut this term is actively being redefined.

[charlescook-ph]

The target audience for those products though are all non-technical and won't care that they aren't literally an OS. I suspect an engineer would find us less credible/roll their eyes? (I am aware that engineers are capable of not thinking literally though...)

[simfish85]

Tried the following options with someone from our Ideal Customer Profile on a demo just now:

• ProductOps Platform
• Product OS
• Product Data Platform
• Product Platform

He said that Product Data Platform best explained what we do.

[joethreepwood]

Catching up on this after some time away.

• Product OS: I really like this, but agree with Charles that it is only being actively redefined by non-technical products to sound more technical. That creates a risk for us.
• Product Data Platform: This is clear, but also limiting. And, to me, high-level positioning should indicate an ambition or vision beyond what the product is strictly capable of.

Personally, I believe our positioning must come from our mission. Here are some quick, new ideas of a deliberately different style to try and shake us free from this blockage.

• The Engineer's Product Platform
• The Open Source Platform for Product Builders
• The Platform for Building Better Products
• The Platform for Product-Led Teams
• The Product Improvement Platform
• The Product Insight Platform

[camerondeleone]

I really like those riffs @joethreepwood

I feel like using the term Product-Led Growth might be a good way to keep us grounded in something that "actually" exists. That implies eng/product managers are the target audience, but still keeps it open enough, I think.

• The Platform for Product-Led Growth
• The OS for Product-Led Growth
• The Data Platform for Product-Led Growth

[joethreepwood]

Personally, I think we should be mission-based. E.g.: All the tools you need to build better products.

…

On Thu, 23 Jun 2022, 09:26 Marcus Hyett (PostHog), ***@***.***> wrote: I would advocate for being a little more explicit with some of these sentences since people will have different interpretations of what a product platform might be (e.g. I think JIRA when I hear Product Platform, not hotjar) Perhaps extending: All the tools you need to be: All the tools you need to understand your users or something else that anchors the sentence in what the tools are needed for. — Reply to this email directly, view it on GitHub <#3620 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUA6UKIDG3Z5Q456OJSVTF3VQQNUZANCNFSM5ZCSU72Q> . You are receiving this because you commented.Message ID: <PostHog/posthog. ***@***.***>

[jamesefhawkins]

For what it's worth "what does PostHog do" I now normally answer as:

We provide an open source product operating system. We combine all the tools you need to build a better product, in one place.