[HN Gopher] Launch HN: June (YC W21) - Product Analytics for B2B...
___________________________________________________________________
Launch HN: June (YC W21) - Product Analytics for B2B SaaS Companies
Two and a half years ago my co-founder and I left our jobs on the
product team at Intercom to try and build a startup. We went
through YC and launched an analytics tool on top of Segment that
allowed you to generate some pre-made reports for common product
metrics (https://news.ycombinator.com/item?id=26155327). We raised
a seed round, then spent a year building templates of reports for
startups. After a year of building our product we tried to
monetise and failed. Our free users weren't willing to pay us money
for individual reports. Among the users we had, there were a
handful of later stage B2B companies with few customers but a lot
of revenue (one had 50 customers and $1m in annual revenue). These
companies looked at their analytics in a different way. They cared
a lot more about specific individual users than consumer apps do,
and they spent a lot of time using our product. After learning
this we spent some time trying to understand the differences
between product analytics for a B2C product versus a B2B one. We
learned three main things that led us to pivot our company into
building a product analytics tool for B2B SaaS companies: (1) Most
of the revenue in B2B products comes from a handful of customers.
In Slack's case, 500 customers out of 700,000 made up to 40% of
revenue[1]! (2) Most of the revenue B2B products make comes from
expansion. Contracts start small and grow over time, as a company
wins more trust and delivers value. This means that growing product
usage among existing users, over time, draws in more users and more
revenue. (3) Product management in B2B is a lot less quantitative
than in B2C. It is more a collaboration with Sales and Customer
Success teams. The kind of insights you need from analytics are
different. You need to know "Are our key customers adopting the new
feature we launched?" and not "Does our new redesign improve
activation by 2%?" After learning these things we went back to the
drawing board and rebuilt our product with them in mind. That is,
we built a product analytics tool that (1) has automatically set up
reports that allow you to track acquisition, activation, retention
and feature usage; (2) supports measuring metrics both in terms of
how many users or companies use your product; and (3) helps you
answer common questions for your users like "Who used our product
the most in the last 90 days?", "Who tried our new feature once and
never came back?", "What's our feature with the highest retention?
How many people use it?" This realization happened a year ago and
we've now reached the point where more than a thousand B2B SaaS
companies at seed and Series A use us every month. We would love
to get some feedback from the broader HN community! You can find
our product at: https://june.so [1]
https://www.fool.com/investing/2019/04/29/slack-relies-heavi...
Author : 0xferruccio
Score : 77 points
Date : 2023-06-28 12:57 UTC (10 hours ago)
| debarshri wrote:
| When you have simple SaaS platform, a platform like amplitude or
| mixpanel is generally enough capture these metrics. You can
| create these funnels in that product. The level of customization
| in these tools is pretty good too. You can add more advanced
| metrics and track them. You can segment customers, you can do
| alot of things. You can start with a basic tool, but everyone
| eventually moves to an advance product like amplitude or mix-
| panel for SaaS.
|
| You product feels very lightweight.
|
| One of the problem we have in my current startup is that we have
| multi-tenant customers, different deployment methods - on-
| prem/managed etc. Platforms like amplitude, do not cater to these
| types of models. So, instead we built our own
| datawarehouse+metabase setup that gives us very granular control,
| reliability and assurance over the data, as well as we built lot
| of custom metrics.
|
| Would love you hear your thoughts.
| 0xferruccio wrote:
| Hey debarshri thanks for your comment. I'll reply inline to
| your points as I think others on the thread might have the same
| question
|
| > When you have simple SaaS platform, a platform like amplitude
| or mixpanel is generally enough capture these metrics. You can
| create these funnels in that product. The level of
| customization in these tools is pretty good too.
|
| It's true that you can create most of the features in June in
| Mixpanel or Amplitude. Setting up June as a small company
| though will take a lot less time and give you out of the box
| the most important things that you should be looking at.
|
| As an example here's an email from one of our users:
| https://imgur.com/a/UO1ZPOZ
|
| > You can start with a basic tool, but everyone eventually
| moves to an advance product like amplitude or mix-panel for
| SaaS.
|
| Interestingly we see the opposite, most of our paying customers
| were Mixpanel or Amplitude users that weren't using those tools
| that much because of the effort involved to get some valuable
| information, preferring a simpler product for a shorter time to
| value
|
| The way we see it is that in the long run - as we develop our
| product more and more, companies will have something like June
| for any use case that is not unique to their business (like
| launching a new feature, activating users, see how your biggest
| customer uses your product etc..) and a data warehouse with a
| BI tool for every analysis that is unique and only relevant to
| your specific business.
|
| That being said right now we see that companies from the Series
| B stage onwards graduate out of using June and that's totally
| fine for us for now. You can read more about our approach to
| building our product here (https://www.june.so/blog/reaching-
| product-market-fit)
|
| > One of the problem we have in my current startup is that we
| have multi-tenant customers, different deployment methods - on-
| prem/managed etc. Platforms like amplitude, do not cater to
| these types of models. So, instead we built our own
| datawarehouse+metabase setup that gives us very granular
| control, reliability and assurance over the data, as well as we
| built lot of custom metrics.
|
| One of the things we're built for is that for every event you
| send you can specify what tenant performed that action and
| every report works both at a user level and at a company level.
| (see: https://help.june.so/en/articles/6789004-how-to-track-
| compan...) For other tools company tracking is an add-on to the
| core product, for us it's the core.
|
| So not only you know how many users use your product, but you
| can look at the behaviour of individual tenants for every
| metric you're looking at. Additionally for every tenant we
| automatically generate reports for that specific company, so
| when your Customer Success or Sales people hop on a call with
| customers they have answers to questions like "how much are
| they using our product?", "who are their top users?" and "have
| they started using all of our core features?"
|
| It's a long answer, but hope it addresses some of your doubts
| :)
| andreshb wrote:
| Every time I try to do time-series cohort analysis or Lifetime
| LTV expandability on many of the analytics tools out there I get
| frustrated and up resorting to Tableau. It took mixpanel a decade
| to finally get some of it right but it's still too simple. I
| don't like tableau but it sure beats doing custom SQL queries all
| the time. How do you handle cohort analysis?
| 0xferruccio wrote:
| I'd love to learn more about what your needs are in terms of
| Cohort analysis and what brings you back to SQL.
|
| We have a retention report which works for both users and
| companies and allows you to quickly spin up retention cohorts
| kareemm wrote:
| Been watching your journey for a while. You've hit on a couple of
| key insights that I think are really smart because they
| accelerate TTV which historically has been sloooow in the metrics
| space (been watching and using tools in this space since
| Kissmetrics was in beta):
|
| * B2B SaaS is a lot more qual. than B2C (We also sell to B2B
| SaaS[1] and this squares with what we've seen). You don't need to
| cater to all the scenarios that Amplitude or Mixpanel or Heap
| cater to which narrows the scope of what to ask of users (and
| what you need to build!)
|
| * Honing in on SaaS means you can offer canned AARRR reports and
| key feature usage reports out of the box which massively
| accelerates that.
|
| * Pulling metrics from where they already live and transforming
| them into immediately useful data for PMs. CDPs like Segment
| enable that but you could even de-risk customer migration to June
| by pulling data from Mix or Amplitude
|
| Congrats on hitting 1k customers. Looking forward to seeing where
| you go next.
|
| 1 - https://www.savio.io
| 0xferruccio wrote:
| Awesome to hear that what we're doing resonates! Appreciate the
| support :)
| marban wrote:
| I understand that everybody wants to be the next Notion but I
| would suggest moving away from the Somalian TLD trend. Zero
| credibility and probably prone to all kinds of blockers.
| nkko wrote:
| I totally don't understand this, when and why this started? Was
| it really just cause of Notion?
| krammer wrote:
| Heavy and happy early user of June here.
|
| I'm also a heavy user of Amplitude and I see how June solves many
| of my common use cases in a more usable way.
|
| Probably for me it doesn't make a huge difference, and I still do
| deep analysis at my dwh or amplitude. But for the rest of the
| org, that is less data oriented, I found that June increases
| their data driven mindset just by making it easier to understand
| and use.
|
| That's what good UX is for.
| tomredman wrote:
| Love to see this guys, great work and love to this pivot working
| for you.
| codegeek wrote:
| How are you different than Posthog (another YC comoany)?
| 0xferruccio wrote:
| The main differences are that we're only doing product
| analytics and are focused on building a product for B2B SaaS
| companies. Our users are product/engineers/sales/success people
| looking at product usage and are too small for A/B tests to
| make sense.
|
| Posthog's value prop is that it's all-in-one, it's open-source
| and it's built for engineers.
|
| Additionally, in my experience when a company wants to self-
| host their analytics June, Amplitude or Mixpanel aren't even
| considered as an option and Posthog is the go-to tool.
|
| As much as our products cover similar use cases, in the day to
| day we don't really see much overlap in terms of target
| customers
| msencenb wrote:
| I heavily considered June recently for my b2b saas (they even
| offered my tiny bootstrapped startup a small discount for the
| first year, which I appreciate very much).
|
| The thing that stopped me was that there was no way to track an
| event to only a company, it still had to be tied to a user with
| the identify call. Our most important metrics ($ processed per
| company) is not based on a user at all. I wish June let you do
| company only event tracking - I would have had to hack in a fake
| user to track against.
|
| Lots of our other metrics are per user, so we did like that it
| was possible to tie it to users-just surprising that an analytics
| company focused on org level analytics required it.
|
| Also on the wishlist - hubspot integration. I've been evaluating
| Hightouch to punch data from my app to hubspot and it's probably
| going to work, but take more effort than I was hoping for.
|
| Best of luck!
| 0xferruccio wrote:
| Hey there thanks for the nice words!
|
| > The thing that stopped me was that there was no way to track
| an event to only a company, it still had to be tied to a user
| with the identify call.
|
| I'm not sure why this is completely blocking you, we have
| plenty of customers that just create a user with user_id
| "system" to track actions that aren't tied into a specific user
| in a company.
|
| There isn't really any drawback to that approach as you can
| filter out the system user from every analysis that doesn't
| want to include them! Happy to support you on the
| implementation or answer any further doubts in our Intercom
| conversation thread :)
|
| > Also on the wishlist - hubspot integration. I've been
| evaluating Hightouch to punch data from my app to hubspot and
| it's probably going to work, but take more effort than I was
| hoping for.
|
| We do have a June to Hubspot integration, and will be building
| a deeper integration in the next months (that being said it's
| not part of our free plan)
|
| Anyways thanks for the feedback and hope to see you come back
| in the future
| jroseattle wrote:
| > we have plenty of customers that just create a user with
| user_id "system" to track actions that aren't tied into a
| specific user in a company
|
| I'll try to add some context around this for my use case: we
| need to track items at various levels within an organization.
| Company, division, team, user -- and that's flexibility I
| need by customer. These are contextual interactions with our
| customers, and we're not always interacting with actual
| users.
|
| > There isn't really any drawback to that approach as you can
| filter out the system user from every analysis
|
| There is a drawback for us. Forcing everything to a "system"
| user means we have to manipulate and skew how our customers
| interact with us to map into this product analytics product.
| This is important to us because we don't want everything to
| boil down to a user, even if it's just a "system" account.
|
| This might not be so important with your other customers, so
| your mileage may vary.
|
| Thanks for listening!
| 0xferruccio wrote:
| If you're up for it I'm happy to hop on a call to
| understand a bit more your use case as I'm not sure I
| understand correctly. (email met at my first name @june.so)
|
| > There is a drawback for us. Forcing everything to a
| "system" user means we have to manipulate and skew how our
| customers interact with us to map into this product
| analytics product. This is important to us because we don't
| want everything to boil down to a user, even if it's just a
| "system" account.
|
| I'm not sure I understand the end user impact between how
| your customers use your product and how you model the
| things you measure.
|
| If you analyse your data only at a company level it doesn't
| really matter that the user in the company that you're
| assigning an action to is called "system". The only things
| that matter are the dimensions you use to analyse your data
| - and if in your event data there's a field you use like
| the "group_id" of the entity you're analysing and a field
| for a "user_id" called "system" that you ignore.
|
| The only thing we force you to do is structure information
| as an event stream with timestamps!
|
| That being said if you have a product with multiple levels
| of grouping like "Company, division, team" you wouldn't be
| able to attach one action to all three, you'd just be able
| to assign it one by one (and probably would have to send an
| event for each)
|
| Again happy to support on a 1:1 basis if that helps
| msencenb wrote:
| Thanks for the reply. We do plan on taking another pass at
| analytics in July or August. I'll give the system user_id a
| try, it's entirely possible that will work for us and I have
| simply not gotten to an aha moment yet with the product (we
| are starting from scratch, so no segment data to import).
|
| > I'm not sure why this is completely blocking you, we have
| plenty of customers that just create a user with user_id
| "system" to track actions that aren't tied into a specific
| user in a company.
|
| It was never a technical problem, but a cognitive dissonance
| between the marketing and implementation details. I'll do my
| best to narrate my internal dialogue as a potential buyer.
|
| I come to the homepage and am intrigued by the words "focused
| on companies"--because that is absolutely what I want! I want
| company level metrics (sports teams in my case) to be the
| first class citizen. I actually do not care about user
| identification at all. There are a ton of products that
| already do that I can pick if I want. I assumed you might be
| able to drill down into user level metrics eventually, but I
| thought our v1 would not identify users at all.
|
| Jumping over to the docs, I head to the tracking behavior
| section for companies. The user_id param being required does
| not fit with my idea of what June is at this point. Why would
| I need to identify a user, if this analytics is focused on
| companies?
|
| To me, this data model suggests that this is a traditional
| analytics product that treats user + user events as first
| class, then rolls that up to do clever things at the analysis
| level for companies. I had expected company events to be the
| first class citizen and for the events to flow top down from
| there. Now I'm concerned that when I stick in a 'team'
| user_id the data is going to be muddied, because the product
| won't know that this hacked in ID is just a generic company
| thing. Does that mean my user based analytics are going to be
| off? What does that imply for the data/reports downstream?
|
| > There isn't really any drawback to that approach as you can
| filter out the system user from every analysis that doesn't
| want to include them! Happy to support you on the
| implementation or answer any further doubts in our Intercom
| conversation thread :)
|
| This comment highlights what I mean. If you are an analytics
| company focused on tracking companies, I expected it to just
| work that way out of the box. If I need to remember to filter
| out this user from a bunch of metrics or analyses, I am bound
| to forget at some point or bring on a teammate who doesn't
| know.
|
| Anyways, thanks again for the reply and hope the feedback is
| helpful.
| 0xferruccio wrote:
| Hey Matt thanks for the follow up explaining here!
|
| I appreciate the feedback here on the user/company focus.
| That being said I think that as our focus is to help you
| understand how companies use your product it's actually
| essential to also track users.
|
| A lot of our customers use June to understand who are the
| internal champions within a company - at what stage of
| activation each user within a company is etc...
|
| In the end companies are groups of people and most of the
| time you really want to make sure that multiple users
| within the companies that use your product are active. And
| without tracking users you can't really do that!
| Androider wrote:
| "Just remember to filter out special user IDs x, y, z,
| they're actually companies" is exactly the type of
| problems that when you solve will make the customer go
| "oh, this maps _exactly_ how I think about company
| events/metrics".
|
| If you're "focused on companies", just add a company
| level event/metric API even if it's all sugar and you
| internally model it with user IDs or whatever. I don't
| think anyone is saying tracking user events isn't
| important, it obviously is, just that in addition you
| should introduce company events to truly differentiate
| yourself from the "ordinary" analytics providers.
| tough wrote:
| group them by organization/company like any teams /auth
| would do? let you aggregate per org besides user
| sidcool wrote:
| Seems like you just launched it in June. BTW, why did you name it
| June?
| 0xferruccio wrote:
| We didn't plan it this way, but we felt we had to launch before
| the end of the month :)
|
| My co-founder Enzo (the CEO) came up with the name because when
| starting out the feeling we had was that most analytics
| products felt cold and intimidating and our goal was to build
| something that feels warm and welcoming - like June
| matdehaast wrote:
| June is quite cold in the southern hemisphere ;)
| 0xferruccio wrote:
| Haha, you're right! Perhaps our next product will be called
| December to balance things out for our southern hemisphere
| friends.
|
| We already have https://july.so
| pjot wrote:
| The july.so page says "taking you to the future" and
| redirects to june - wouldn't that be the past? Have you
| registered may.so?
|
| Great product though! Will be following y'all's progress!
| tomredman wrote:
| Next June!
| MoSattler wrote:
| Just a quick heads-up, your marketing site seems quite slow on
| Safari for Mac.
| 0xferruccio wrote:
| Thanks for reporting this - I think we need to optimise some of
| our heavier animations and lazy load some of them :)
| roncohen wrote:
| June is cool. Best of luck!
|
| Would you consider adopting the STARS framework[1] ? It was
| designed to solve the questions you mentioned like "Are our key
| customers adopting the new feature we launched?" but at the same
| time it also incorporates qualitative feedback.
|
| [1] http://starsframework.org/
|
| Full disclosure: I helped design it.
| 0xferruccio wrote:
| We kind of ended up building something that overlaps with our
| feature report - but we just stop at the STAR, we haven't
| really looked into adding qualitative information like
| satisfaction to our product, but it could make sense!
| mrcwinn wrote:
| We sell both to customers and businesses. Help me rationalize
| having two analytics products.
___________________________________________________________________
(page generated 2023-06-28 23:01 UTC)