A story about pivots(posthog.com)
posthog.com
A story about pivots
https://posthog.com/blog/story-about-pivots
38 comments
Would you be willing to expand a bit on the user tests? surveys? Counting signups for interest? I'm wondering about other ways to test without a MVP
Sure! It depends a lot on the product. But in our case, a key interaction was on Facebook. So we pretended to be doing market research on social media and brought a lot of people in for user tests. Eventually we'd have them log in to Facebook on our test computer, asking them what they though of various posts.
What they didn't know was that we used Greasemonkey to alter the Facebook page, inserting fake feed items using their real friends. (We told them at the end if they didn't figure it out.) Some people liked what we were doing, but a lot hated it. So many that it was clear we'd never get the market penetration we wanted.
My cofounder did a 5-minute video talk about it if you'd like more details. https://vimeo.com/24749599
As an aside, surveys are worse than useless for this. Look for things that let you understand live user reactions in circumstances that are as real as possible. Signups are a good metric, especially if they'll give you a credit card number up front. But if you can, always back the metric with live user tests and discussion with real users. If you're patient and ask good questions, you can learn a ton.
What they didn't know was that we used Greasemonkey to alter the Facebook page, inserting fake feed items using their real friends. (We told them at the end if they didn't figure it out.) Some people liked what we were doing, but a lot hated it. So many that it was clear we'd never get the market penetration we wanted.
My cofounder did a 5-minute video talk about it if you'd like more details. https://vimeo.com/24749599
As an aside, surveys are worse than useless for this. Look for things that let you understand live user reactions in circumstances that are as real as possible. Signups are a good metric, especially if they'll give you a credit card number up front. But if you can, always back the metric with live user tests and discussion with real users. If you're patient and ask good questions, you can learn a ton.
cool thanks for sharing!
(i think from that video this is your market) it seems like influencer marketing is a thing now, though I might guess you were looking at more 1:1 not social media celebrity:many
(i think from that video this is your market) it seems like influencer marketing is a thing now, though I might guess you were looking at more 1:1 not social media celebrity:many
Yes, our goal was to help people make better buying decisions. In the real world, this is frequently a social process. Influencer marketing is sort of the opposite of what we were aiming for.
Would you be open to discuss points 2 and 3 - the key assumptions that were wrong - a bit more?
I honestly no longer recall. My cofounder gives a short talk here that will give you an idea, though: https://vimeo.com/24749599
Great story! What happened to the two other companies? Did they fail?
They did fail. For what it's worth, we did as well. I think our eventual product idea was much better than our first one, though, and I think our fatal mistake was not about lack of user demand, but on building too much on the theory that we could use Facebook for viral growth. As we were about to go for our A round Facebook changed a lot of things to de-emphasize apps and posting to people's feeds, so our growth numbers fell off a cliff. Turns out investors only like hockey sticks when they go up.
One is Uber and the other is Lyft.
> the best failures are those with the smallest craters.
what a fantastic quote!
what a fantastic quote!
One pro-tip when building a product that you don't yet have product market fit for is to be a bit more general in your technology choices and naming conventions.
Ideally, you don't lose 100% of the work you've done in the past when pivoting. The database should ideally stay the same with the infra, deployment tools, etc. The code structure should stay similar with various internal libraries (i.e. logging, synching data, etc.)
In a way, it also help to make good architecture decisions because rather than hack a one-off, it's easier to spot the right abstractions that can be re-used across products.
Same with naming.. instead of naming all your things based on the product name, just use fun/code names, so when you pivot or re-brand, you don't have to rename everything or need to deal with legacy product names.
Ideally, you don't lose 100% of the work you've done in the past when pivoting. The database should ideally stay the same with the infra, deployment tools, etc. The code structure should stay similar with various internal libraries (i.e. logging, synching data, etc.)
In a way, it also help to make good architecture decisions because rather than hack a one-off, it's easier to spot the right abstractions that can be re-used across products.
Same with naming.. instead of naming all your things based on the product name, just use fun/code names, so when you pivot or re-brand, you don't have to rename everything or need to deal with legacy product names.
This is a gem! They did _exactly_ what one should do to build a new business: find market fit _before_ spending a ton of time on an idea, even if you're "passionate" about it. As engineers, it's very easy to get overly attached to an idea or project, specially when it seems you're the only one it resonates with, or you've invested a lot of time on it already.
Best of luck to PostHog!
Best of luck to PostHog!
There’s is a fine line though. They actually spent a lot time on building things. You could even argue they could have gotten there earlier in some cases. But in general I agree!
Hey, James... Thank you for offering me a code to get a PostHog mug shipped, but I won't use the code now. I'll use it when you get to a few billion dollars of revenue. It's rude to turn down a gift and I want my mug : D
All the best to you and your team :)
All the best to you and your team :)
Is the mom test actually worth the money? I’ve seen it touted in a few places and again here.
How much can you change an MVP and intended customer and still call it a pivot?
Eric Ries, the guy who coined the term, has 2 categories: pivots and leaps. The analogy he used is basketball footwork. If you keep one foot planted, it's a pivot. Reviewing the article:
1 -> 2: Pivot, as it's still in sales.
2 -> 3: Pivot, as they kept the sales focus and "predictive analytics".
3 -> 4: Seems like more of a leap.
4 -> 5: Pivot, as it's still developer surveys.
5 -> 6: Leap.
Both are fine, honestly. But one should favor pivots over leaps, as you have less to re-do. A leap is a desperation ploy.
1 -> 2: Pivot, as it's still in sales.
2 -> 3: Pivot, as they kept the sales focus and "predictive analytics".
3 -> 4: Seems like more of a leap.
4 -> 5: Pivot, as it's still developer surveys.
5 -> 6: Leap.
Both are fine, honestly. But one should favor pivots over leaps, as you have less to re-do. A leap is a desperation ploy.
Nice to learn the origin of the term in this context. My only other exposure to it is through SQL
Ha! I never thought of the terminology this way - some of these are hops some are pivots!
As a user and (recent) contributor to PostHog, I find it pretty incredible how good enough it is for such a young product, and the pace of releasing new features.
I really hope you'll be able to sustain it.
I really hope you'll be able to sustain it.
Great write-up.
> Along our journey (/series of failed ideas), we got frustrated having to send all our user data to 3rd parties to understand our product usage. It felt wrong and it meant we'd lose a bunch of user data that would have been quite useful. So we built PostHog.
I wouldn't call PostHog a pivot, but rather focusing on something else entirely, and really solving one's own pain-points; often a well-trodden way of finding product-market fit [0].
> There were a load of features we wanted conceptually - but it was when we realized that the strategy was being open source first and foremost that we felt more excited than we ever had before. When that clicked, we knew we'd just fallen in love with this idea. We started building on January 23rd, 2020.
Given 'tis the season of FOSS projects pivoting to non-FOSS licenses; as a FOSS developer, I am interested in PostHog's pivot from "FOSS alternative to Heap / Amplitude" to "source-available" [1] instead :)
[0] https://archive.is/66opo#selection-118.161-118.162
[1] https://github.com/PostHog/posthog/blob/master/ee/LICENSE
> Along our journey (/series of failed ideas), we got frustrated having to send all our user data to 3rd parties to understand our product usage. It felt wrong and it meant we'd lose a bunch of user data that would have been quite useful. So we built PostHog.
I wouldn't call PostHog a pivot, but rather focusing on something else entirely, and really solving one's own pain-points; often a well-trodden way of finding product-market fit [0].
> There were a load of features we wanted conceptually - but it was when we realized that the strategy was being open source first and foremost that we felt more excited than we ever had before. When that clicked, we knew we'd just fallen in love with this idea. We started building on January 23rd, 2020.
Given 'tis the season of FOSS projects pivoting to non-FOSS licenses; as a FOSS developer, I am interested in PostHog's pivot from "FOSS alternative to Heap / Amplitude" to "source-available" [1] instead :)
[0] https://archive.is/66opo#selection-118.161-118.162
[1] https://github.com/PostHog/posthog/blob/master/ee/LICENSE
We do have a completely FOSS version here: https://github.com/posthog/posthog-foss :). The only difference is support for Clickhouse and some advanced permissioning stuff.
My favorite story of a pivot comes from anon on HN [1]:
In 2009, the startup where I was working was hitting the skids, and our investors (correctly) were not willing to back us. We all kept grinding for a month or two in honorable futility, but after a while, my bank account depleted and I had to go.
To make various ends meet and to keep my mental health during the wind down however, I took up some contract work that I found through various friends in the SF startup scene. One company that I really liked and did some small stuff for was Burbn, which was a mobile-only location check-in that was hinged around taking photos of your location.
Missing my friends in NYC (I made a lot of friends in SF, but my inner circle were my college buddies from CMU; I went to tech and they went finance, sigh), I decided to leave SF to head to NYC and get a fresh start.
As I was leaving, I wanted to tie up a few loose ends, so I emailed my contact at Burbn and said I was likely to be unavailable for any more work, but that I liked the project and hoped for the best for him. He responded and said that he was near funding on a small pivot, and that if I was interested, there might be a full-time role available. I declined - I was mentally done with SF and the startup scene (Larry Chiang, 111 Minna, the rise of FB spam-crap like RockYou, etc.) as it was then.
That person was Kevin Systrom; that pivot was Instagram.
[1]: https://news.ycombinator.com/item?id=18063362
In 2009, the startup where I was working was hitting the skids, and our investors (correctly) were not willing to back us. We all kept grinding for a month or two in honorable futility, but after a while, my bank account depleted and I had to go.
To make various ends meet and to keep my mental health during the wind down however, I took up some contract work that I found through various friends in the SF startup scene. One company that I really liked and did some small stuff for was Burbn, which was a mobile-only location check-in that was hinged around taking photos of your location.
Missing my friends in NYC (I made a lot of friends in SF, but my inner circle were my college buddies from CMU; I went to tech and they went finance, sigh), I decided to leave SF to head to NYC and get a fresh start.
As I was leaving, I wanted to tie up a few loose ends, so I emailed my contact at Burbn and said I was likely to be unavailable for any more work, but that I liked the project and hoped for the best for him. He responded and said that he was near funding on a small pivot, and that if I was interested, there might be a full-time role available. I declined - I was mentally done with SF and the startup scene (Larry Chiang, 111 Minna, the rise of FB spam-crap like RockYou, etc.) as it was then.
That person was Kevin Systrom; that pivot was Instagram.
[1]: https://news.ycombinator.com/item?id=18063362
Super impressed with your story and how much progress you've made. It sounds like you're constantly taking action, even though some might argue about the pivots or hops you've made.
I'm curious about a few things.
I'm most curious about the tactics you all used to find potential users and customers to talk to. Aside from using the YC network, were you going on LinkedIn and doing cold out reach?
Less important but how crappy/embarrassing were the MVPs you were showing people?
I'm curious about a few things.
I'm most curious about the tactics you all used to find potential users and customers to talk to. Aside from using the YC network, were you going on LinkedIn and doing cold out reach?
Less important but how crappy/embarrassing were the MVPs you were showing people?
The weird thing was that the people I'd helped with nothing in it for me ended up being the best place to start. It was often friends at startups who need a website building, or some friendly advice.
That's not super helpful if you've not already done that:
* Real life groups were pretty helpful. You can't go to these aiming to sell, but if you go aiming to learn and genuinely just get advice, they work well. * LinkedIn was pretty good, looking for people that I knew through others and asking them really nicely if I could talk about something we wanted to build. When we had better ideas that solved pain points they had, that were more unique, the response rate was much higher. This doesn't work well for "recruiter-saturated" user profiles like developers, who just ignore a lot of what goes on there.
The MVPs weren't that bad - they'd work smoothly on the things that were new and special BUT they often totally lacked core functionality. We built with django so we could use django admin to do things like add users/change passwords.
That's not super helpful if you've not already done that:
* Real life groups were pretty helpful. You can't go to these aiming to sell, but if you go aiming to learn and genuinely just get advice, they work well. * LinkedIn was pretty good, looking for people that I knew through others and asking them really nicely if I could talk about something we wanted to build. When we had better ideas that solved pain points they had, that were more unique, the response rate was much higher. This doesn't work well for "recruiter-saturated" user profiles like developers, who just ignore a lot of what goes on there.
The MVPs weren't that bad - they'd work smoothly on the things that were new and special BUT they often totally lacked core functionality. We built with django so we could use django admin to do things like add users/change passwords.
To me the biggest takeaway is, as always, you should care about what you're building, or you're unlikely to find success.
Stated another way: the goal shouldn't be to build something, but to solve a problem for someone. Building should be a means, not an end.
posthog looks like a great product. But it's interesting that a product offering with "open source" and "on your infrastructure" still has "cloud" as the first tab in the pricing. (Not a criticism at all, just pointing out the interesting dynamics of the open core business model)
We're about to change our deployment strategy actually!
We think the future for open source is offering private cloud, where we have some sort of control pane to manage upgrades without needing access to your data. That's a win for privacy reasons but mean we don't have to go at the pace of our users with the least powerful on premise servers.
We think the future for open source is offering private cloud, where we have some sort of control pane to manage upgrades without needing access to your data. That's a win for privacy reasons but mean we don't have to go at the pace of our users with the least powerful on premise servers.
That sounds interesting. Out of curiosity does AWS have streamlined support for vendor deployments? (I don't work in large organizations so have never seen how non-saas deployments work)
A decade back I co-founded a startup. My cofounder, a brilliant product manager, had what seemed like a great idea. Great enough that he quickly got a fat check for the whole seed round. We could have just started building, but both of us were big fans of using user testing to guide product development, so we instead did a lot of user tests.
Six or eight weeks later, we were down at Sand Hill Road for our first board meeting. At this point, according to our VCs, normally they'd just hear about plans. But my co-founder got up and explained that of the 6 key assumptions in our product, 2 and maybe 3 were false. The thing they'd given us money to build was a bust. The room was very quiet. Then he went on to explain the next idea we'd come up with and got them excited about that.
Something we learned later is at the same time we'd raised a seed round, two other companies raised large A rounds to go after basically the same idea. They spent the next 18 months (and north of $10m) trying to make it work.
Not only did that make us feel a lot better about having pivoted, but it was an important lesson to me: the best failures are those with the smallest craters. We bought the same knowledge for less than 1% of the money spent.