• Product
  • Pricing
  • Docs
  • Using PostHog
  • Community
  • Company
  • Login
  • Table of contents

  • Handbook
    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Small teams
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
    • Team structure
    • Customer Success
    • Exec
    • Experimentation
    • Growth
    • Infrastructure
    • Marketing
    • People & Ops
    • Pipeline
    • Product Analytics
    • Session Recording
    • Website & Docs
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Side gigs
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • How to interview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Working with product design
      • Releasing a new version
      • Handling incidents
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • How-to access PostHog Cloud infra
      • Developing the website
      • MDX setup
      • Markdown
      • Jobs
      • Overview
      • Data storage or what is a MergeTree
      • Data replication
      • Data ingestion
      • Working with JSON
      • Query performance
      • Operations
        • Overview
        • sharded_events
        • app_metrics
        • person_distinct_id
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
    • Overview
    • Product metrics
    • User feedback
    • Paid features
    • Releasing as beta
    • Our philosophy
    • Product design process
    • Designing posthog.com
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
    • Growth reviews
  • Table of contents

  • Handbook
    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Small teams
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
    • Team structure
    • Customer Success
    • Exec
    • Experimentation
    • Growth
    • Infrastructure
    • Marketing
    • People & Ops
    • Pipeline
    • Product Analytics
    • Session Recording
    • Website & Docs
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Side gigs
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • How to interview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Working with product design
      • Releasing a new version
      • Handling incidents
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • How-to access PostHog Cloud infra
      • Developing the website
      • MDX setup
      • Markdown
      • Jobs
      • Overview
      • Data storage or what is a MergeTree
      • Data replication
      • Data ingestion
      • Working with JSON
      • Query performance
      • Operations
        • Overview
        • sharded_events
        • app_metrics
        • person_distinct_id
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
    • Overview
    • Product metrics
    • User feedback
    • Paid features
    • Releasing as beta
    • Our philosophy
    • Product design process
    • Designing posthog.com
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
    • Growth reviews
  • Handbook
  • Customer success
  • Sales operations
  • Demos

Demos

Last updated: Sep 19, 2022

On this page

  • Giving great demos
  • Initial call
  • Demo
  • Environment
  • Guidance

Want to see PostHog in action? Book a PostHog demo with our customer success team, or try our live demo environment.

Giving great demos

Always focus on delivering what the customer needs. Sometimes that will mean sending them to a competitor or turning them down.

Initial call

The purpose of this call is to work out what the potential customer needs.

Don’t be presumptive - ask why they reached out. It’s often a very quick way to understand what they need, but there will likely be adjacent challenges you can also uncover.

You are trying to work out:

  • Does the client prefer ease over saving money or vice versa?

  • How should the client deploy (i.e. cloud or self-hosted with support). This will depend on their volume and price sensitivity.

  • Does our functionality meet their use case? Would it be worth going ahead with what we have now?

  • Is the client going to need us to do most of the work? If this is the case, support is really important e.g. because they’re growing very fast.

  • How much analytics experience does the client have? More experience means you should focus more on how we are different, less experience means you should try to keep things simple.

As a rule, always understand the context behind the question - it may help you make further useful recommendations.

Demo

Environment

When doing a demo of PostHog, you should prioritize using the following environments:

  1. The client's own instance or PostHog Cloud account (if they have one and are OK with this).

    This is the best way to do a demo because you can help the client with their exact needs and you show them how to do what they want with their own data, so they immediately see the value.

  2. The PostHog Demo Environment

    The demo instance was designed to be an environment with a significant amount of "good" demo data that showcases the multiple features of PostHog and allows clients to log in and run the demo themselves (while following your instructions).

    To run a demo on the demo environment, you should:

    1. Have access: Ask Yakko or James to give you access if you don't have it.
    2. Invite the client to the instance: Invite them to the instance so that they can have access themselves without you having to share credentials.
    3. Guide the client through a demo while they share their screen: Take them for a spin of the product as you would do if you were the one navigating. But be patient, the client might want to click around and get a feel for PostHog, which is encouraged!
    4. Revoke their access at the end of the call: After the call, revoke the client's access to the instance or ask Yakko to do it if you do not have permission.
  3. A local environment

    This is best if you have a good set of demo data locally. You can use some our management commands for data generation to do this.

  4. PostHog Cloud

    Only demo using PostHog Cloud (on the PostHog team account) if you really have to. Be careful not to expose sensitive data when doing the demo.

Guidance

Show the client the product. Pause frequently and make sure there are no questions. Ask if the functionality would help them.

Use this to confirm the benefits to the customer that PostHog needs to provide. If you are talking only about feature X does Y, then you’re doing it wrong. "As a Product Manager, I may want to know 'X' about my users, this is how you do that."

#### Follow Up

Keep this as quick as possible - if you can follow up immediately / on the same day, do it.

#### Feature Requests

Sometimes client calls will highlight features that they would need which we don’t have. Your first step is to work out if what we do will be valuable enough to move forward with. Avoid committing to new functionality unless you’re already about to work on it. It’s better to underpromise and overdeliver.

#### Style

  • Be passionate: "This is one of my favorite parts of the system", "the neat thing about X is Y"
  • Social Proof: If your current users are using something, or if you built something for a really specific reason, let the client know (obviously without naming names). This helps people know they're not the first to use PostHog!

Questions?

Was this page useful?

Next article

Billing

Managing billing (V2) With the addition of our "V2" Billing architecture, billing for self-hosted and cloud is almost identical, with all PostHog instances talking to a common external Billing Service . This service is the single point for managing billing across PostHog Cloud US, PostHog Cloud EU and self-hosted customers. It leans heavily on our payment provider Stripe for both showing what products are available as well as controlling things like free-tier allowances. Key differences to…

Read next article

Authors

  • Andy Vandervell
    Andy Vandervell
  • Charles Cook
    Charles Cook
  • adrienbrault
    adrienbrault

Share

Jump to:

  • Giving great demos
  • Initial call
  • Demo
  • Questions?
  • Edit this page
  • Raise an issue
  • Toggle content width
  • Toggle dark mode
  • Product

  • Overview
  • Pricing
  • Product analytics
  • Session recording
  • A/B testing
  • Feature flags
  • Apps
  • Customer stories
  • PostHog vs...
  • Docs

  • Quickstart guide
  • Self-hosting
  • Installing PostHog
  • Building an app
  • API
  • Webhooks
  • How PostHog works
  • Data privacy
  • Using PostHog

  • Product manual
  • Apps manuals
  • Tutorials
  • Community

  • Questions?
  • Product roadmap
  • Contributors
  • Partners
  • Newsletter
  • Merch
  • PostHog FM
  • PostHog on GitHub
  • Handbook

  • Getting started
  • Company
  • Strategy
  • How we work
  • Small teams
  • People & Ops
  • Engineering
  • Product
  • Design
  • Marketing
  • Customer success
  • Company

  • About
  • Team
  • Investors
  • Press
  • Blog
  • FAQ
  • Support
  • Careers
© 2022 PostHog, Inc.
  • Code of conduct
  • Privacy policy
  • Terms