New product page

[corywatilo]

To coincide with the reframing around PostHog being a platform with apps (#3265), it was time for a new product page.

→ Full WIP wireframe

Preview of the top section:

This product page has sections for each of the platform benefits, broken down into the following:

1. Overview
2. Screenshots (because what developer born in the 80s doesn't love a website with screenshots?)
3. Apps
4. Event pipelines
5. Data warehouse
6. Self-hosting
7. SQL & data access
8. API

I'd love some eyes on this to make sure we're covering the important points. (Some sections are light on content at this point.)

Currently accepting comments in Balsamiq (right rail) or here is fine, too.

cc @jamesefhawkins, along with @fuziontech @yakkomajuri for content suggestions – and to make sure I'm phrasing this stuff correctly

---

Note: This also coincides with a new Product dropdown menu (first seen in this Figma), which matches up with the sections outlined above.

[corywatilo]

WIP Figma mock

[joethreepwood]

Ah, awesome. This may help clarify something I've been wondering about lately.

In terms of insights, we have lots of different types and not all of them (Lifecycle, Retention) aren't featured on the /Product page. We could give each of these a page on their own, or we could lump them together under a 'Product Analytics' label which would also cover Funnels and Trends (which do get their own page). One approach massively increases the level of content/detail on the page, the other burys content/detail.

Wondering what your thoughts on this are for the new design?

[corywatilo]

In the "apps" line of thinking, every analysis view should have its own page. (We'll have to figure out how it actually fits in the app, but we can decouple this.)

If we have content for these lesser-used analysis views, we should make app pages for them!

[corywatilo]

Content-complete wireframe

New sections include:

• Data Warehouse copy
• API copy

The only semi-weird thing is, because this page was geared around core product features being separate apps, this page doesn't cover all of that. Need to figure out a way to highlight the top features (the current product pages) ideally without adding subsections for analytics, insights, experimentation (The apps model sort of breaks down if we just don't classify all functionality as apps*...) - as the purpose of this subnav was to highlight the breadth of the platform outside of just product analytics.

*If we don't group our product features into the apps bucket, apps really just get relegated to being plugins - just with a new name. ☠️

Link to Balsamiq

[corywatilo]

Update: I've added a section called Top features to call out all the existing feature pages, with slightly different groupings. This section can work (for now) separate from apps, but can also serve as a different want to show "featured apps" in the future when we make apps great again.

[corywatilo]

New product page is nearly complete, minus the hero which will get updated after the new homepage messaging is fully live. But all the content below the hero is passable.

How the Product section fits together

Here's what I'm proposing based on this dropdown menu:

You can get straight to the main product page either by clicking the Product top-level nav item, or by clicking Product overview. (We'll also link to this page from throughout the site.)

Features column

These all map to existing pages already, so we link straight to them (with a new template, which is TBD - to be designed).

/product/funnels
/product/trends
/product/user-paths
/product/collaboration
/product/session-recording
/product/feature-flags
/product/experimentation-suite
/product/correlation-analysis
/product/heatmaps

We can use all the content we have today on those pages, but present it a little better - and likely in a way that flows you linearly through each of the product pages in the dropdown.

We'd tie these subpages into the product section's sidebar that flows something like this (not final design):

The above would live on the main product page, and the subpages to replace this current list:

Data stack column

None of these really have dedicated marketing pages yet, so I suggest we anchor them to the relevant sections in the main product page (Figma above).

/product#event-pipelines
/product#data-warehouse
/product#self-hosting
/product#sql
/product#api

Each of them basically link into docs articles from there, so it makes more sense to cover them here but work on better designed docs "index" pages where each of those link to. (cc @pjhul)

The only exception from data stack column list that's not mentioned above is the App library which would link to /apps. (Ultimately we'll probably want a top-level nav item that says Apps, but we're a bit away from that.)

Since Apps still lives in the product section for now, we should use the same /product sidebar as above. In essence, it will look/feel like you're in the product section if you just don't look at the slug: /apps

[corywatilo]

Here's what a product show page could look like.

Note: Incomplete comparison table

[joethreepwood]

This design looks great -- my only thought is if we're ordering the content correctly. It feels like users would be most likely to visit the product section when they're in a discovery/evaluation stage of a buyer journey -- not when they are existing users. Existing users will have deeper questions and will likely go straight to the Docs or Squeak.

With that in mind, is it worth putting the comparison table higher up the page and moving the Docs links and tutorials lower down the page?

[corywatilo]

SQL & data access section

Since we're downplaying Self-host Enterprise (which, to my knowledge, was the only way to get direct SQL access), is it worth killing off this section? (It doesn't sound like we're planning on bringing this to Cloud anytime soon?)

cc @camerondeleone @fuziontech

[camerondeleone]

@corywatilo any self-hosted instance can execute queries directly against clickhouse. While it's slightly misleading to claim that we give you sql access (because that implies a productized sql editor, to me at least), it's still technically correct. Maybe just 'database access' is sufficient here.