7 ms·

A story about pivots

127 points by james_impliu 6y ago

progre 6y ago
How much can you change an MVP and intended customer and still call it a pivot?
- james_impliu 6y ago
  Ha! I never thought of the terminology this way - some of these are hops some are pivots!
- wpietri 6y ago
  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.
  - progre 6y ago
    Nice to learn the origin of the term in this context. My only other exposure to it is through SQL
danr4 6y ago
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.
ignoramous 6y ago
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 https://archive.is/66opo#selection-118.161-118.162 [1] https://github.com/PostHog/posthog/blob/master/ee/LICENSE https://github.com/PostHog/posthog/blob/master/ee/LICENSE
- timgl 6y ago
  We do have a completely FOSS version here: https://github.com/posthog/posthog-foss https://github.com/posthog/posthog-foss :). The only difference is support for Clickhouse and some advanced permissioning stuff.
SamuelAdams 6y ago
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 https://news.ycombinator.com/item?id=18063362
147 6y ago
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?
- james_impliu 6y ago
  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.
tylermenezes 6y ago
To me the biggest takeaway is, as always, you should care about what you're building, or you're unlikely to find success.
- thisisbrians 6y ago
  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.
wpietri 6y ago
I really appreciate when people are transparent. There's a lot of good wisdom here. 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.
- Winterflow3r 6y ago
  Would you be open to discuss points 2 and 3 - the key assumptions that were wrong - a bit more?
  - wpietri 6y ago
    I honestly no longer recall. My cofounder gives a short talk here that will give you an idea, though: https://vimeo.com/24749599 https://vimeo.com/24749599
- baxtr 6y ago
  Great story! What happened to the two other companies? Did they fail?
  - keithwhor 6y ago
    One is Dropbox and the other is Box.
afterwalk 6y ago
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)
- james_impliu 6y ago
  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.
  - afterwalk 6y ago
    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)
Jugurtha 6y ago
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 :)
FL33TW00D 6y ago
Is the mom test actually worth the money? I’ve seen it touted in a few places and again here.
- foxgrover 6y ago
  Yes
- snarkypixel 6y ago
  yes!
- james_impliu 6y ago
  A thousand times yes.
herval 6y ago
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!
- baxtr 6y ago
  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!
snarkypixel 6y ago
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.

127 points by james_impliu 6y ago

progre 6y ago

How much can you change an MVP and intended customer and still call it a pivot?

james_impliu 6y ago
Ha! I never thought of the terminology this way - some of these are hops some are pivots!
wpietri 6y ago
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.
- progre 6y ago
  Nice to learn the origin of the term in this context. My only other exposure to it is through SQL

danr4 6y ago

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.

ignoramous 6y ago

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 https://archive.is/66opo#selection-118.161-118.162 [1] https://github.com/PostHog/posthog/blob/master/ee/LICENSE https://github.com/PostHog/posthog/blob/master/ee/LICENSE

timgl 6y ago
We do have a completely FOSS version here: https://github.com/posthog/posthog-foss https://github.com/posthog/posthog-foss :). The only difference is support for Clickhouse and some advanced permissioning stuff.

SamuelAdams 6y ago

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 https://news.ycombinator.com/item?id=18063362

147 6y ago

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?

james_impliu 6y ago
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.

tylermenezes 6y ago

To me the biggest takeaway is, as always, you should care about what you're building, or you're unlikely to find success.

thisisbrians 6y ago
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.

wpietri 6y ago

I really appreciate when people are transparent. There's a lot of good wisdom here. 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.

Winterflow3r 6y ago
Would you be open to discuss points 2 and 3 - the key assumptions that were wrong - a bit more?
- wpietri 6y ago
  I honestly no longer recall. My cofounder gives a short talk here that will give you an idea, though: https://vimeo.com/24749599 https://vimeo.com/24749599
baxtr 6y ago
Great story! What happened to the two other companies? Did they fail?
- keithwhor 6y ago
  One is Dropbox and the other is Box.

afterwalk 6y ago

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)

james_impliu 6y ago
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.
- afterwalk 6y ago
  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)

Jugurtha 6y ago

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 :)

FL33TW00D 6y ago

Is the mom test actually worth the money? I’ve seen it touted in a few places and again here.

foxgrover 6y ago
Yes
snarkypixel 6y ago
yes!
james_impliu 6y ago
A thousand times yes.

herval 6y ago

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!

baxtr 6y ago
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!

snarkypixel 6y ago

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.