We set a goal of 100K users by October and hit 300K

We officially formed our PLG team in late April.

Really, we formalized our platform team, pointed everyone at a single goal, and said: grow.

Because as much as we’re a startup, we’re still an organization with goals, so naturally we picked a completely reasonable one: 100K users by October.

It was ambitious.

The executive team was excited. The team turned a little green. There were definitely a few sidelong looks suggesting they were trying to figure out whether Kris and I were serious.

We were. And we had a plan.

The hardest part of that plan wasn’t even the execution. It was the buy-in.

From the outside, some of what followed probably looked like YOLO chaos, led, and occasionally instigated, by Kris and me.

From the inside, it was something much more intentional: belief in the team, a willingness to move before we had perfect answers, and a people-first approach to how we wanted to build.

The team had goals. Our goal was the team.

Over the next six months, somewhere between the custom emojis, endless dogfooding, experiments, bug bashes, GitHub outages, and increasingly ambitious targets, we learned a lot about what it actually takes to grow a product this quickly.

Some lessons were technical. Some were about product. Some were about data.

And a surprising number were really about confidence, judgment, and learning how to work together when the answer wasn’t obvious.

So rather than tell that story from one perspective, we asked the people who lived it.

Here are a few of the lessons from the team that, in the words of Kris, absolutely SMASHED the goal.

Fix the Funnel: Build an Experience That Doesn’t Suck | London Davila & Zachary Lyon — Software Engineers

Early on, we treated growth as one big number. That’s fine. It tells you something is broken without ever telling you what.

To move it, we broke the funnel apart and treated every step as part of the product, because every step is a place where someone can quietly decide we’re not worth it.

Our first onboarding flow was a grid of agent harnesses: Claude Code, Codex, Hermes, OpenClaw, Grok, Pi, OpenCode, OMP. You clicked yours, copied an install command, pasted it in the right place, and hoped nothing broke.

It worked. But it also put nearly all of the work on the user. So we flipped it.

Instead of asking users to figure out installation themselves, we gave them one prompt to hand to their agent and let the agent install TinyFish.

That made the experience simpler, but it also exposed a whole new category of failures.

Once agents were running the installs, we found out just how many ways things could break that had nothing to do with our code. Users were missing the harness they thought they had. Their harness didn’t support MCP without a plugin. Their local setup wasn’t what we expected.

From the user’s perspective, none of that distinction mattered. TinyFish just didn’t work.

So we shipped roughly 33 CLI versions to npm in a month, each adding telemetry, better prerequisite checks, clearer errors, or some combination of all three. We tested flows across macOS, Windows, and Linux.

And we learned one lesson the hard way: when you see a steep drop-off, check your instrumentation first.

More than once, the scary cliff was just an event that wasn’t firing.

QA changed too. It used to be a final check before release. But, then we got Hans. With Hans testing everything from onboarding to CLI installs to the playground, it became part of how the product got built.

He wasn’t just asking whether things worked. He was asking whether they made sense.

That shift from “find bugs” to “understand the experience” helped us fix the rough edges that mattered instead of the ones that were simply the loudest.

We A/B tested constantly, and we learned to do it with a real hypothesis, metrics decided up front, and enough run time to reach significance.

Most wins were only a few percent. But funnels are multiplicative, so small lifts compound.

Some of our best wins came from removing steps entirely.

For example, clicking our ChatGPT plugin during onboarding used to open an instructions panel linking to the plugin page, which already had an install button. We cut the panel.

Installs went up. Usage went up. Users can’t drop off at a step that doesn’t exist.

Metrics tell you where people leave. They do not tell you why.

So we signed up, onboarded, installed, broke it, and did it all again until everyone was sick of the signup flow. We went through competitors’ flows too, partly to borrow good ideas and partly to remember what a bad experience feels like.

Ultimately, you cannot optimize a funnel you do not understand as a user.

Once we could see where the experience was breaking, the next question got harder:

Which problems actually mattered, and how would we know if our fixes worked?

Data, Experiments, and Knowing When to Trust Yourself | Kate Zhang, Software Engineer

Growth is, in many ways, a math problem.

If the top of the funnel is healthy but the outcome is not, there is a leak somewhere.

The first challenge is finding it.

At the beginning, that meant figuring out what was actually worth measuring. We had plenty of data available, but more data does not automatically mean more clarity.

We had to decide which behaviors represented real progress through the funnel, which events were reliable enough to trust, and which numbers were interesting but not necessarily useful.

Then we had to learn how to read that data. Together. Because my read wasn’t Kat’s and it wasn’t Zach’s or London’s. Our own experiences colored how we read that data.

Growth cannot depend on one person becoming the keeper of the dashboard.

If an experiment affects onboarding, product, engineering, or activation, the people making those decisions need to understand what the numbers are saying and, just as importantly, what they are not saying.

Over time, our process became more disciplined (most of the time. Okay, sometimes).

Start with a hypothesis. Decide what success should look like before running the test. Choose the metrics up front. Run the experiment long enough to get meaningful signal. Then interpret the result and make a decision.

That sounds obvious. It is much harder in practice.

Samples can be small. Signals can be noisy. Multiple parts of the product are often changing at the same time. Instrumentation can fail. Sometimes a result points clearly in one direction. Sometimes it gives you just enough information to create three more questions.

The biggest lesson was that data reduces uncertainty. It does not eliminate judgment.

At some point, you have to decide that you know enough to move. Or you all agree enough to try it anyway.

Waiting for perfect certainty can be just as bad as moving too quickly.

The goal became less about asking, “Can the data make this decision for us?” and more about asking, “Do we have enough signal to make a decision ourselves?”

That shift mattered. Confidence is not ignoring the data. It is knowing when the data has told you enough.

And once we trusted both the signal and our own judgment, the next question changed.

We stopped asking only:

What converts? And started asking: What would we actually want to use?

Build Something You’d Actually Want to Use. Then Keep Building It | Joshua Munsch, Designer & Uttam Bharadwaj, Software Engineer

One advantage of building tools for people who work with AI and developer products all day is that we are also the target user.

Not in the abstract “we understand our persona” sense. We actually use this stuff.

We install tools. We test models. We try new workflows. We get annoyed when setup takes too long. We notice when a feature feels awkward. We appreciate when something quietly does exactly what we expected it to do.

That experience became another source of signal.

Not the only source. But a useful one.

“Would I use this?” is a surprisingly effective product question.

If something annoyed us every single time we used it, that was worth paying attention to.

If something felt unusually smooth, that was worth paying attention to too.

And if we kept reaching for a capability that didn’t exist yet, that was probably worth an even closer look.

That became an important part of how we thought about the product.

Improving conversion was not only about removing friction from the funnel. It was also about making TinyFish more useful once someone got through it.

That meant constantly asking what was missing.

Is there a capability users expect us to have? Is there a shortcut that makes a common workflow easier?

Is there something we can add that turns a one-time experiment into a product someone wants to come back to?

A lot of my (Uttam!) work lived in that space: noticing the gaps between what the product could do today and what would make it meaningfully more useful tomorrow. That’s what led me to build Vault and Browser Context Profiles.

Sometimes I proposed a new feature. Sometimes I pushed an existing one further.

Sometimes the best product improvement was not a giant launch at all, but one small capability that removed a repeated annoyance.

That mindset paired naturally with the design side.

Design was never just the layer we added after the “real” work was done. It shaped whether the product felt worth using.

The best version usually came from combining several kinds of information at once:

What did the funnel tell us? What did the experiment tell us? What were users doing? What did we keep noticing ourselves? What capability did the product still need? What did Josh say?

Then we built something. Used it. Tested it. Learned from it. Changed it. Applied the Josh treatment.

And built again.

The important distinction is that we were not building for ourselves instead of listening to users.

We were close enough to the problem that our own experience could become one more useful input alongside user behavior, testing, and data.

We still listened. You still measured.

But our product intuition started with something much simpler: This should be better than it is.

We combined taste, data, and our constant eye for what the product still needs, to make it less about isolated features and more about a complete suite and a real product.

That required people willing to argue about ideas, test each other’s assumptions, hand work back and forth, and keep moving.

The Team Was the Strategy | Kristopher Szeto, PLG Tech Lead

I adore this team.

It was a true joy watching them go from, “100K wuuuuuh? What is growth hacking???” to, “Oh yeah, that’s easy. Let’s go.”

It took us a little time to get there.

We all had our own personalities and working styles. We were worried about stepping on each other’s toes. We were worried about making silly mistakes. We were still figuring out who owned what, when to jump in, and when to get out of each other’s way.

But once we realized that we all genuinely cared about each other, had each other’s backs, could have fun and be silly together, and that nobody gave a f**k about mistakes or failing, we hit our stride.

A few things really stand out to me about what makes this team special.

One team

We tackle most problems as a team.

We actually tried carving out dedicated areas and swimlanes for individuals, but most projects end up converging into a group effort anyway.

Part of that is just reality. The team is small, startups change constantly, and the thing that looked like an engineering problem yesterday might suddenly involve product, data, QA, or design today.

But it’s also because we genuinely enjoy working together.

We help each other. We ask for opinions. We hand things back and forth. We pull each other into problems. We lean on each other all the time.

Over time, people also got much more comfortable taking ownership. There was less waiting for permission and more, “I see the problem. I’m going to take this.”

That matters a lot on a small team.

The goal was never to make everyone stay perfectly inside their lane.

The goal was to make sure the right problems got solved.

Not afraid of failure

I don’t think anyone on this team spends much time worrying about making mistakes, breaking production, or shipping a feature that flops.

Sure, sometimes we do clowny shit. Not intentionally, we swear.

And sometimes we get overzealous.

But overall, the team learned that taking risks lets us move fast, learn fast, and swing for the fences.

We do our best to be responsible grown-ups. Yes, we test our code. Yes, we think about what can go wrong. Yes, we try very hard not to light production on fire.

But we also know that almost every bug, mistake, bad experiment, or breakage is fixable.

That gives people room to make decisions.

As a tech lead, that also means resisting the urge to jump in and solve everything myself. Sometimes I could do something faster. Sometimes I already know how I would approach it.

But if I do that every time, I become the bottleneck.

A strong team needs people who are trusted to make decisions, try things, occasionally get them wrong, and learn from what happens next.

That trust compounds.

Optimize for doing the right thing

We’re ambitious and we want the business to be successful.

But more importantly, we want to build a great product that delights people.

We believe that if we focus on doing that well, business success follows.

Startups are noisy and messy. There is always another metric, another idea, another thing someone thinks we should be doing right now. It is very easy to get distracted.

This team has gotten really good at blocking out that noise and coming back to a simpler question:

What is the right thing for the product and the user?

Sometimes that means chasing an experiment.

Sometimes it means fixing something unglamorous.

Sometimes it means killing an idea we were excited about.

Sometimes it means ignoring the shiny thing and making the thing we already have actually good.

That focus is a big part of why this worked.

We started with a huge goal and a group of people who were still figuring out how to operate together.

What we ended up building was a team that trusted each other enough to move quickly, disagree, make mistakes, take ownership, and keep going.

I’m so incredibly proud of this team, and I’m really excited to see what comes next.

We set out to hit 100K users.

We hit 300K.

That’s the visible result.

The more interesting thing we built was the team that could get there.