kunggaochicken

Joined 3 months ago

Karma
9
Submissions
8
Member since
Aug 2
just trying my best
View on Hacker News

Recent submissions

Comment · 1 month ago
While working on my own startup, I realized that there are many components of customer discovery that I can systemize. I built continual outreach to help automate customer discovery campaigns - and autotune aspects of the loop based on the hit rates. For each hypothesis/campaign:

Build your Campaign:

1. Continual Outreach interviews you for your ICP (and ideally their pain points)

2. Lock in your ICP profile as the core agent policy

3. Continual Outreach runs qualifies candidates with computer use to research the web for your ICP and public artifacts they might produce for their hypothesized pain.

4. Send them a connection on LinkedIn with a personalized message based on step 2 that aligns with a general campaign message template

5. Store those into a spreadsheet (i.e Google Docs)

Once Candidates respond (or ghost):

1. Update the spreadsheet with warm/cold signals

2. Update the ICP policy based on the research that led to qualifying the candidate

3. Continue this loop as long as you wish

I've gotten 30 connects so far (out of 80 sent) and 3 calls booked out of those (most connections connect without resopnse so I have 27 followups to do :) ). I know LinkedIn has some connection limits so I limited the request rate. But I believe (hope) that higher connection rates will afford more leniency towards LinkedIn's algorithms and I'm hoping this can be one of the features that the continual policy update can pick up on down the line to be more aggressive in connection requests.

LinkedIn is just the surface that I found useful for my use case, but it should theoretically generalize towards email outreach, twitter dms, etc so long as you have a browser tool connected to those outreach channels. Contributions are very welcome, especially in the continual reinforcement side of things!

Comment · 1 month ago
great question! the verifier pass actually operates more as an "assistant" gate so we can expand the token vocabulary.

jev allows 255 decisions (token vocabulary here), so if we want to support a token vocabulary of 1000, we have to parallelize into multiple jev calls to allow that expansion. the verifier pass simply chooses the best out of the parallel decisions so we can exceed the 255 decision limit. in theory this should allow for up to 255^2 token limit, but if you increase the verifier depth you can increase that exponential factor as much as you want (it'll be slow though)

Comment · 1 month ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton