Add RFC: Streamline startups workflow #285
Conversation
| * Use PostHog-the-app to filter by whether a user has clicked that or not, and show a banner that says “🎉 You’re eligible for the startup plan! Get started here.” | ||
| * Build a new page on the app: /project/###/startups | ||
| * Host the completion steps of the form here. | ||
| * * All we need to ask for is what we don't already know. I think that's just "How much in total funding have you raised (USD)" and "The date that your company was incorporated." |
There was a problem hiding this comment.
I guess to make things easier we can automatically apply the credits immediately, but then asynchronously check whether they're actually allowed to get them and reverse if not?
| ## What can we do about it? | ||
| - **Steps 2 and 3,** above, should not have to happen. (We already have a record of *most* of the info, because a PostHog account is required to apply.) | ||
| - I think this means the actual **sign-up form should be gated**, accessible from the app itself — requiring a user to be in a logged-in state to submit. | ||
| - I think the system should **auto-filter applications:** if they are not eligible, do not apply the credits. *(We can write nice rejections: “Did we get that wrong? Contact Scott if you think there’s been a mistake. We like being generous, but sometimes the our auto-bots are fierce defenders of the realm.”)* |
There was a problem hiding this comment.
Love this language as a fallback option, btw
|
|
||
| ## What can we do about it? | ||
| - **Steps 2 and 3,** above, should not have to happen. (We already have a record of *most* of the info, because a PostHog account is required to apply.) | ||
| - I think this means the actual **sign-up form should be gated**, accessible from the app itself — requiring a user to be in a logged-in state to submit. |
There was a problem hiding this comment.
This is actually a brilliant solution if we can find a way to make it work within the app.
Do you have an idea on where it would sit? Billing page would seem a good choice, to me. We could also use this as an opportunity to implement the billing badges I proposed a while ago and which I think @raquelmsmith and @patricio-posthog have been hoping to ship this quarter too.
There was a problem hiding this comment.
We'd definitely want to keep the existing /startups page on PostHog.com, right? We can just have the 'Apply now' button direct to the relevant area of the app and cut the form.
There was a problem hiding this comment.
@joethreepwood Thank you! Your billing badges idea sounds like a brilliant way to do this. It would surface the available tier at just the right spot.
(This comes with the assumption that each of those plan tier badges would link to their own page to go into more detail on what it's involved?)
Yep, for sure we have to keep the /startups page on PostHog.com. As you say, we would just need to re-think the CTA.
| * I get a little lost in the plumbing after this and am asking for support thinking through the path. | ||
|
|
||
| ## Three other considerations: | ||
| * **Solving for the YC program too:** It needs similar care, as the form at [yc-onboarding](https://posthog.com/yc-onboarding) generates all the same challenges. It has the same issue of manual back and forth that causes too much friction. The same issues apply, and I think a similar solution can be considered. |
There was a problem hiding this comment.
The slight difference here is that we need to check that the person is in the YC program by their Bookface access, and we really want them to hit 'Using this deal' on our Bookface page. However, maybe we can have that be part of a white-glove service handled by the proposed YC Implementation hire.
| ## Three other considerations: | ||
| * **Solving for the YC program too:** It needs similar care, as the form at [yc-onboarding](https://posthog.com/yc-onboarding) generates all the same challenges. It has the same issue of manual back and forth that causes too much friction. The same issues apply, and I think a similar solution can be considered. | ||
| * **Solving for other deals:** Besides the YC deal, PostHog will continue to set up other deals with other accelerators / VC programs. It would be smart to think of this as a workflow we can replicate and edit the minor details for emerging deals. | ||
| * **Solving for internal reporting:** Because so many systems are talking to one another here, there is a lot of manual reporting between Zapier tables, Stripe data, Salesforce, Vitally and PostHog to get a source-of-truth view of how our startups programs and YC adoption is doing. I think if we can find ways to let the systems do the talking, we should hopefully result naturally in cleaner data, but if we can undertake this job with this in mind, we'd be even better off. |
There was a problem hiding this comment.
@minekansu I think you're the expert of the Zap and Vitally side of things, so just tagging you in case you have Thoughts
Suggestions for improving the way we manage incoming startup applications