search

PostHog / posthog.com

Official docs, website, and handbook for PostHog.
https://posthog.com
Other
437 stars 448 forks source link

Update homepage hero messaging #3620

Closed corywatilo closed 2 years ago

corywatilo commented 2 years ago

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

image

Positioning

Design

Navigation

andyvan-ph commented 2 years ago

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:

corywatilo commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

Screenshot 2022-06-20 at 11 16 04

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 commented 2 years ago

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 commented 2 years ago

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

corywatilo commented 2 years ago

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

image Updates:

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

joethreepwood commented 2 years ago

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

Screenshot 2022-06-21 at 10 36 17

is sublime.

jamesefhawkins commented 2 years ago

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

charlescook-ph commented 2 years ago

This is nice, beautifully done team!

Only two things I have an opinion on:

corywatilo commented 2 years ago

Figma updates:

marcushyett-ph commented 2 years ago

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 commented 2 years ago

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:

image

simfish85 commented 2 years ago

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 commented 2 years ago

+1 to @simfish85

andyvan-ph commented 2 years ago

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 commented 2 years ago

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[bot] commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Product Optimization Platform?

jamesefhawkins commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

You're not an Operating System

Yes buuut this term is actively being redefined.

image image image image

image

charlescook-ph commented 2 years ago

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 commented 2 years ago

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

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

joethreepwood commented 2 years ago

Catching up on this after some time away.

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.

camerondeleone commented 2 years ago

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.

joethreepwood commented 2 years ago

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 https://github.com/PostHog/posthog.com/issues/3620#issuecomment-1164109966, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUA6UKIDG3Z5Q456OJSVTF3VQQNUZANCNFSM5ZCSU72Q . You are receiving this because you commented.Message ID: <PostHog/posthog. @.***>

jamesefhawkins commented 2 years ago

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.