Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product builders who made the leap from Big Tech to a startup.

Tools shape culture

During my decade at Facebook, I watched the company grow from 500 million users to more than 3 billion and scale to over a hundred thousand employees. Despite this massive growth, what kept the company feeling like a startup (nimble and fast-moving) was the tooling.

These tools shaped Facebook’s innovation culture. They allowed orgs to distribute decision-making to small teams, maintain precision, and move quickly even as the company grew beyond “a startup.”

This realization influenced my decision to start Statsig. I was convinced that the right tools can shape engineering cultures across companies of all sizes.

Now, after four years of building a startup in Seattle, I've extrapolated this perspective beyond a single company to an entire ecosystem: how do you shape the innovation culture across a city?

If tools shape the culture of a company, then startups shape the culture of a community.

Seattle’s competitive advantage

Sitting on stage with Ben Gilbert at the inaugural Seattle Startup Summit, we reflected on the region's unique position.

As we covered in our fireside chat, Seattle has such a strong concentration of talent. We have robust experience building at scale for large companies, and are highly motivated to build some really, really cool things from scratch.

Seattle has an extraordinary competitive advantage. We're home to two trillion-dollar companies, Microsoft and Amazon, and host significant offices for nearly every major tech player.

As Ben highlighted, "despite the fact that this room looks large, there's still like one one-hundredth the number of companies in the Bay Area and maybe one one-hundredth the local capital." This disparity in the number of startups exists in Seattle despite housing hundreds of thousands of engineers.

All that to say, Seattle’s talent pool often feels unnoticed and underappreciated. It feels like a “quiet talent.”

The activity that goes on behind the scenes

What struck me most while walking the expo floor was how many incredible companies I had no idea existed - and even more surprising, how many I didn't realize were based right here in Seattle.

From AI model deployment startups like OpenPipe to developer tools like Spice AI, these companies are building the tools that will shape the next generation of software development. Many are founded by veterans of our tech giants who understand deeply what developers need.

The Summit represented something we've been missing in Seattle - a tool to scale our culture. At Statsig, we've hosted smaller gatherings, but nothing on this scale. This was one of the largest tech startup events in Seattle's history, bringing together over 600 attendees and showcasing dozens of companies operating in relative isolation from each other.

We need more ways to build connections among startups and those looking to make the leap from Big Tech. Whether that be online or offline forums, more (virtual) doors being opened can lead to more cohesion.

Startups shape culture

At Statsig, we're doubling down on our commitment to the Seattle ecosystem. We're investing in more community events, opening our office for meetups, and creating programs specifically for startups to use our tools.

The Seattle tech community doesn't need to imitate Silicon Valley. We have our own strengths. What we do need is to make the invisible visible. To create more moments where the community can see itself, connect, and grow stronger together.

Seattle doesn't lack technical talent or innovative ideas. What we've missed are the regular touchpoints that transform a collection of companies into a true ecosystem.

Let's build on this momentum together.

Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product builders who made the leap from Big Tech to a startup.

How I approached joining a startup

After five years at Meta as a Staff Data Scientist, I took the leap and joined Statsig as their first Data Scientist.

At the time, I was excited by the idea of building something from scratch—but also nervous about leaving the security of Big Tech.

Four years later, it’s been a rocket ship, growing to 100+ employees, helping thousands of customers run >5k concurrent experiments while processing 1 trillion rows a day.

Through this journey, I’ve had the privilege of working with top-tier Data Scientists from companies like OpenAI, Atlassian, and Notion. This experience has been transformative, exciting, and pretty darn scary. I’m hoping that by sharing my experience, other data professionals can learn:

• Whether a startup is right for you

• What the tradeoffs are

• How to choose the right startup

While others may describe joining a startup as a leap of faith, an emotional, or an impulsive decision, for me, it was anything but. I approached this decision the same way I approach my work: thoughtful, data-driven, and grounded in experience.

Why consider a startup?

I loved working in Big Tech. It had generous compensation, world-class colleagues, impactful problems, and work-life balance.

Startups, however, are a different beast, and the rewards—both personal and professional—can be immense. Some benefits you can expect:

• Total Ownership: At a startup, you own your work in a way you do not at Big Tech. There isn’t a network of checks and balances. You may be the only expert at your company on a specific topic, and folks will look to you. The success of the company depends on you. You’re not a part of a machine any longer, and you’ll feel the immense weight and responsibility. But doing what’s right and landing quality work feels amazing.

• Speed: I hated long review cycles, endless alignment meetings (including the notorious “meeting before the meeting”), and layers of sign-offs across a nebulous organization. At Statsig, I learned that if something is important, just do it. If you need to make sure others are aware, you just walk over and have a quick conversation. If you need help, convince someone it’s important. No one is going to tell you, “but this isn’t on my roadmap.” You are in control of the pace of your work.

• Accelerated Growth: The pace of learning at a startup is unmatched. At Big Tech, you are rewarded for being an expert in a specific area; the whole company is full of experts. Startups, on the other hand, thrive on generalists. We have an unlimited set of problems but a limited bench of Data Scientists. People will work on critically important projects, even if they are outside of their core expertise. Successful individuals are undaunted by new problems and are fast at learning.

Choosing a good startup

I’ve turned down opportunities to join a few startups in my career. Some of them I regretted.

Over time, I’ve come to the conclusion that while startups are risky, they’re not equally risky. Some are destined to succeed, while others are headed for failure. I’m also convinced that success is predictable (to a significant degree), and there are traits you can identify before joining.

Here are the traits I looked for when joining Statsig:

• Team Quality: Investors know this…the caliber of the founding team is absolutely critical. A great founding team with a flawed idea can pivot to success. Conversely, a mediocre team with a great idea will get crushed by competitors. Look up the founders’ track records. Do they have the “Midas Touch”? I was lucky because I had previously worked with Statsig’s founding team and knew they were talented, execution-focused, and just plain fun to build with. But you can scour your network and do your research to find people who can vouch for them.

• Industry and Growth Potential: Is the company solving an important problem in a growing industry? Does the industry have only a few critical competitors? The best startups operate in markets that are evolving and expanding.

• Secret Sauce: Does the company have an unfair advantage? Will they be able to win a dogfight against fierce competitors?

If you’re considering joining a more established startup (Series B+), you should also consider:

• Company Trajectory: Is the company gaining customers, hiring great people, and securing funding? A growing company means more opportunities for you.

• Reputation of Employees: The employees will be critical in defining the company’s future. If you respect and admire the team, it’s a strong sign. One trick I’ve found useful: talk to former employees. They’ll give you an unfiltered view of the company’s trajectory, leadership, and culture.

• Makeup of the Team: If you’re a junior employee, you’ll want to make sure there’s mentorship and support from folks you respect. The good news: startups need you to grow into a productive team member, and folks are invested in your success. I’ve unfortunately found that at Big Tech, mentorship is often a checkbox for someone trying to get promoted, and mentees are often paired with mentors who don’t fully understand their work.

Picking a good startup is more than just a job choice—it’s an investment in your future. Being part of tomorrow’s next big thing can be a badge of honor on your resume. It shows you helped build something great.

Closing thoughts

Regardless of your experience, joining a startup can be the best career decision you make. The learning, ownership, and experience you get can have a profound impact on your career. But make sure you’re comfortable with the risk and tradeoffs.

Not all startups are created equal—so do your homework. The right one won’t just be a job; it’ll shape your career in ways Big Tech never could.

Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product builders who made the leap from Big Tech to a startup.

Planning vs Starting

When you're just starting your business, the temptation to "begin on the right foot" can be overwhelming. You convince yourself you need the perfect name, the right domain, and the best logo... and before you know it, the list becomes never-ending.

But here's the thing - you don't need any of those items to get started. What you actually need is to relentlessly focus on the core aspect of your business and core competencies as a founder or small team. Lean into your strengths instead of obsessing over what you're missing. Trust me, you can shore up those shortcomings later in simpler ways than you'd expect.

Take Statsig for example. We started with seven engineers and one data scientist – yeah, a pretty large founding team. But outside of our engineering talent, we had zero branding or design chops. All we had was Vijaye's vision and his iPad sketches. But you know what? It didn't matter. We picked a direction and moved forward.

We knew what we needed to build and roughly what it needed to look like. Sure, we still had a lot of things to figure out before launch, but we didn't let that stop us from starting.

Domain names: Just pick one

Domain names are everything. And nothing. Everyone stresses about getting the perfect one - you know, that short, punchy, easy-to-remember name that seems like it'll make or break your company. And of course, it's got to be ".com", right? Or maybe you can get by with ".io"?

We settled on the company name "Statsig" pretty quickly. It was our internal slang at Facebook for "statistically significant" experiment results. It was fitting for an ex-facebook founding team building experimentation and developer tooling. The only problem: statsig.com was taken.

So we went with the next best thing – statsig.io. Yeah, the ".io" trend in SaaS was probably past its peak, but it worked. You can still see some remnants of our “.io” days - our Github is still https://github.com/statsig-io/.

Shortly after we started and had our Series A funding in the bank, Vijaye decided to reach out to the owner of statsig.com to see if we could purchase it. Turns out it belonged to a university professor who used it for "statistical signal processing" – nothing to do with A/B testing at all!

We managed to broker a deal and purchased it for $14 million. An absolute steal compared to OpenAI's chat.com deal...

Just kidding. It actually cost us $18k (plus GoDaddy's 20% fee), and we were pretty pumped about it! Here’s the email Vijaye received:

On a side note. We didn't realize it then, but we would soon learn that this only fueled Vijaye’s domain purchasing addiction which has taken off.

While statsig.com was by far the most expensive domain we’ve purchased, we've since collected over 50 domains. From statsig.net and statssig.com to more creative ones like abtestingframework.com and launchsmartly.com. The last domain I mentioned has come in handy 😅.

But here's the real point: don't get hung up waiting for the perfect domain. You don’t need to worry about being first in an alphabetical listing like amazon.com, and you can still release a product with a URL like chat.openai.com. Only to move to chatgpt.com and ultimately chat.com once you raise your 6.6B funding round. But you’ll never raise that round if you don't just get started.

Design: Done is better than perfect

Since we were only a group of engineers and data scientists, we did what any scrappy startup would do - we paid for our design. Our first logo was outsourced to Fiverr. We hired a few freelance designers to give us different variations based on Vijaye's sketches and our rough descriptions. Here are the four prototypes that didn't make the cut:

Option 1:

Option 2:

Option 3:

Option 4:

And finally, a variant of the winning logo we ultimately reskinned and launched with:

We've also never stopped iterating on our logo - heck, we’re still tweaking it today.

After launching our beta, we finally hired our first real designer. I think our complete lack of design sense actually made the job more appealing - there was a lot of room to grow!

Within a few weeks, we had the whole package: refreshed brand, new logo, proper design system, marketing assets, and much more. But here's the thing - we didn't need any of that to start. We just addressed it when the time was right.

Focus on your strengths

Look, I'm not saying design doesn't matter when starting up. For some startups, it's absolutely critical (and in that case, it's probably a core competency). If you're building the next Canva or Figma, yeah, maybe nail your design first.

But the principle stays the same - lean into whatever you're good at. If design is your core competency, then build a prototype in Figma. Buy a WYSIWYG website editor to make your first landing page. These days, you can patch up your weak spots pretty cheaply, whether that's design or engineering. Later, you can hire the right people and build those shortcomings into a strength over time.

All this to say: just get started.

Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product builders who made the leap from Big Tech to a startup.

A word from the author: We penned this note before a software bug caused a massive systems outage around the world. Whether we post it now or later, we stand by the message – we’re not advocating for shipping untested features or forgoing release processes. While the catchy title may seem controversial, we encourage you to read the whole post before passing judgment. We’re writing for startups and for entrepreneurs who are pre-product market fit, and for whom speed is everything. In the interest of “shipping before it’s done,” we’ve decided to post this today.

Reviewing what is launch blocking

We have a saying at Statsig - “ship it before it’s done”. It’s a controversial take on the order of “Move fast and break things.” But the longer I work, the more I learn that same lesson over and over.

At face value, people often mistake the saying as a leeway or encouragement to ship a buggy product or a bad experience. Instead, it should serve as a reminder that your customers may not care about the features you see as “launch blocking.” It should force you to reconsider your p0 items, drop dead date, and why you can’t ship part of a larger feature today.

If you don’t get something out there, even if it doesn’t have all the bells and whistles, you’ll be building in a vacuum forever.

You may have noticed this attidue in small ways before. Take this article as an example. I can brainstorm with people what I want to write and ask for feedback on the different topics. But it’s only when I actually put words on paper and riff on ideas, do I get much more actionable feedback. A few small tweaks here, move this up, expand on that story…thoughts that take my musings in a document into a cohesive post worth sharing.

Just pick a direction and go. The sooner you do, the sooner the future decisions reveal themselves. They actually get easier!

Launching in five weeks

The journey at Statsig has been no exception. We started on February 17, and set a goal: launch a beta five weeks later, on March 31. We had an advantage for sure: we started with 7 engineers and 1 data scientist who all knew the tool we were setting out to build.

Many startups spend their first year just trying to hire that big of an engineering team. Others stay in stealth for months or even years, building products in isolation, or with a handful of partners. But we were going to ship the damn thing before it was done!

Building a piece of the vision first

Although we set out to build an entire platform and suite of tools that any company could use, we needed to ship something before that vision had time to materialize. We focused on a single product (feature flags) with one differentiated feature: automatic A/B testing for partial rollouts. We picked a single tech stack to work with, JavaScript on the client and server. And we set out to make it all work.

I’ve worked on SDKs since day one. I still remember figuring out how to set up a new npm package – battling with Babel and Webpack. We didn’t even think to write the packages in Typescript – we just wrote plain Javascript.

On the console side, we had some sketches and design mocks that Vijaye put together. It looked something like this:

We used NextJS for the web app, so we put some API routes in there as well, knowing we could separate out an API deployment later. On day two, our initialize endpoint for client SDKs looked like this

// src/api/sdk/init.ts

export default async (req: NextApiRequest, res: NextApiResponse): Promise<void> => {
  const sdkKey = req.query.sskey as string;
  const userID = req.query.user as string;

  const vc = await EndUserViewerContext.genFromSDKKey(sdkKey, userID);
  const companyID = vc.getCompanyID();
  if (!vc.getUserID() || !companyID) {
    res.json({ success: false });
    return;
  }

  const allGates = await EntityGate.genCompanyGates(vc, companyID);
  res.json({ gates: allGates });
};

For our infrastructure, we knew we would need to handle multiple pods in multiple regions in multiple availability zones, so we started out with two regions, us-east, and us-west.

On the data side, we needed an exposures table and an events table in order to generate event metrics, and some daily jobs to compute experiment results.

And of course, we needed a web landing page, email collection to sign up for updates, and account creation.

The learning comes after the launch

After that month, we could have kept building instead of putting out a beta. Things were still very rough around the edges. We had feature gates and some event logging, but we didn’t have support for multivariate tests, mutual exclusion, custom metrics, mobile apps, or non-Javascript backends (like we do today)…the list went on and on.

But the act of launching forced us to learn how to deploy our applications, publish our SDKs, run our pipelines, and monitor our services. It gave us something we could market – even if it was only to the few people who signed up, our friends and colleagues who watched us leave Facebook to chase this dream.

It helped us hire our first designer, who at least had something to picture and go off of. The fact that it was ugly only made it easier to hire a designer! And it gave us internal feedback. We were all Statsig users at that point and had opinions on how things should look and work.

Had we stayed in stealth mode, we would have built so many features that nobody cared for, and supported integrations nobody needed. But we shipped Statsig before it was done, and we still do that to this day.

The tradeoff of moving fast

The decision to ship instead of staying in stealth represents a massive tradeoff. While I’ve presented the positive side effects of shipping sooner, it doesn’t come at no cost.

Some moments are finite – coming out of stealth, announcing your beta, or publishing version 1.0 is a big moment. If things aren’t in the right place, you could miss out on the set of people who experience your product for the first time. But it’s not just about capitalizing on big moments.

Shipping Statsig added a lot of extra work for our small team. Now, in addition to building out more of the features and functionality of the platform, we also had to spend time on maintenance, release management, real-time monitoring, bug fixes, and public documentation. We also couldn’t make breaking changes as easily.

I remember a few months in having to do a database migration, and since we had actual production data, the process was much more involved than if we could wipe the slate and start clean.

The balance for every startup will be different – your time in stealth mode is a gift, but that time is limited. Statsig will continue to be on the side of shipping sooner rather than later – for us, it has made all the difference.

Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product builders who made the leap from Big Tech to a startup.

The startup (un)learning curve

While working at Big Tech, I’ve taken many products from 0 to 1. During my time there, I believed it was “like being at a startup.” But now that I work at one, I’ve realized it was nothing like it.

As a PM who spent about 7 years in Big Tech (like FB and Uber) before making the jump to startups, I’ve learned a fair share of tough lessons. It took some time for me to learn which habits and working styles seamlessly transition from one environment to the other, and which I should leave behind. Here’s a cheat sheet of some of them.

1. Don’t worry about scale off-the-bat

In Big Tech, you learn to think about the scalability of solutions very early on: how to design a feature such that you can add additional options or controls later, how to architect a system that’s future-proofed for new use cases, etc.

When building in a startup context, there’s not much value in building for scalability on Day One. There’s no guarantee that what you build will resonate with customers and even be around in 3, 6, or 12 months. Your best bet is to take the fastest path to an MVP that delivers true customer value and figure out the “scaling” step if/ when you need to.

After all, a feature taking off and the team scrambling to figure out how to scale it is the best possible failure mode - what a great problem to have!

At Statsig, we’ve seen this play out not just in the product, but in many of the processes we run. Here are a few examples.

Dedicated support for customers

To this day, we still spin up dedicated Slack channels for each and every Enterprise customer who comes on our platform so that we can work with them directly to debug issues, field feature requests, and discuss best practices for data-driven development.

I also include a link to my personal Calendly in our activation email drip campaign to offer customers an on-demand, live help session if they’re getting stuck setting up Statsig. (Yes, even our Free customers who will never pay us a dime can schedule time with me!)

Being involved in every deal cycle

Of course, at some point when something works you do need to start thinking about how to scale it.

A great example is PM owners of new product lines at Statsig are often involved in every single deal cycle for that product early on. This gives them good insight into what questions and feature requests a customer has and where they’re getting hung up on the product and its positioning.

However, being involved in every single deal for a popular product line eventually becomes unscalable. In fact, this involvement can hinder the Sales & Sales Engineering teams’ ability to ramp up on understanding and selling the product themselves.

This is the point where the product owner will build a comprehensive suite of sales enablement materials (conveniently based on their learnings from all those deals they were involved with early on!), and run sales team training sessions, slowly weaning themselves off of being involved with all but the most strategic deals.

Building for scale should come after product-market fit, not before it

Investing in scalability once you already know the product has product-market fit and will be around for a long time to come is high ROI, but doing it on Day One will only lead to extended launch timelines and wasted time/ energy.

At Statsig, we now scale to customers with 100s of millions of users like Flipkart and OpenAI, but we didn’t build features to work at that scale before we knew they were useful.

2. Embrace ambiguity and failing fast

In established companies, unless you’re the CEO, there’s always someone above you who is setting higher-level strategic direction that you can leverage to guide your own product area’s vision and strategy. Furthermore, you’re likely operating in an established, proven business with relatively clear immediate next steps for each business line.

On the other hand, at most startups, nobody knows with 100% certainty what the company should be building or investing in next. Everyone (including the CEO & leadership team!) is on the journey of discerning this together.

The good news is that this can actually be very freeing because it gives you permission to fail fast, and fail often. There are a few examples of where we’ve had to fail a few times before we found our way.

Iterating on our pricing & packaging

We didn’t just fail at this the first time, we’re still continuing to iterate and figure out what works.

Fun story, for our first-ever enterprise customer (a popular web-based productivity tool), we initially quoted them 10x the price of the final contract we signed with them and 5x the price someone “more established” quoted them. Luckily they had the grace to laugh and work with us on finding what worked, instead of walking away. We’re both better for this bet.

Needless to say, we learned our lesson and have approached pricing much more carefully ever since. Pricing is hard to walk back once it’s out in the world, so consider starting at a more conservative offering (it’s much easier to get more generous over time, and significantly harder to take things away!)

Reevaluating our position against competitors

For many months in 2022/ 2023, we watched a new competitor with a warehouse-native model increasingly enter our deal cycles and, slowly but surely, start to beat us out with this novel new deployment. We initially disregarded them and this new model, championing the advantages of our Cloud-based product.

However, with each additional deal we lost, it became increasingly obvious that this competitor had created something the market wanted and we needed to swallow our pride and play catch-up. In mid-2023 we launched our own Warehouse Native deployment option and saw immediate uptake.

The lesson? Have humility, admit when you’re wrong, and constantly be re-evaluating your assumptions.

3. Reset your expectations of what career growth looks like

In bigger companies, career growth at more senior levels almost always correlates with growing teams under you. Initially, you manage ICs, and then grow to manage managers at the Director+ level.

But startups don’t need big teams with multiple layers of hierarchy. In fact, they need the opposite: very few, highly scrappy, high-throughput ICs who are singularly focused on solving problems and driving impact.

The reality of PM work at a startup

So if you’re coming into a startup as a PM hoping to grow your skills as a manager or high-level strategy setter, you may want to reconsider. No matter how senior you were in Big Tech, once you make the jump to a startup, most (if not all) of your time will be spent doing IC work.

Many people love this (I know I do!)- they’re excited to get back to building and being close to the product day in and day out. But for others, especially more senior folks used to being in a pure management role, it can come as a shock.

Similarly, it’s good to be cognizant of what you hope your next career move will be and whether working at a startup will unlock that for you. If, for example, you’re a mid-level PM hoping to get management experience in the next 12-24 months, going to a startup is likely not an optimal move – you’re better off staying at a bigger company where more management roles are needed.

When considering making the jump to a startup, it’s important to know what you’re looking for and be realistic about what your day-to-day will be spent actually doing.

Big Tech → Startup → Resource constrained

One thing becomes clear when you leap from big tech to a startup: you’re on the hook to execute everything. Whether that’s writing blog articles, tech docs, or setting up the internet in the office, if you don’t get to that one thing, it won’t get done.

The resources you leave behind

After handing in your Meta, Microsoft, or Amazon badge, you don’t just give up a cushy job, you’re also leaving behind the resources you took for granted. The hundreds of teams that took care of things you never had to think about.

Maybe you only worked on a small part of the infrastructure or an open-source framework – either way, your engineering scope was fairly limited.

As a product engineer myself, it was an absolute gift not needing to worry about items beyond my tasks at hand. I didn’t have to worry about caching logic for a new feature or building the frameworks that abstracted away database storage.

Heck, I didn't even have to consider marketing or even user acquisition – there were millions of eyeballs on the Facebook app, so even a small fraction of them would give new features very meaningful usage.

At a startup, your “to-do” list becomes infinitely long

But at a startup, all this changes. You’re on the hook not only for your immediate “day job”, but every other team’s jobs as well.

I still remember a few months in, looking around our small office, a handful of us with desks and laptops, and that was it. No one else was coming to help. If the servers had an outage, it was up to the people in that room to figure it out.

Later on, I realized this applied to the business more broadly. Nobody knew about us, and no one else was going to get the word out – but us.

At a startup, beyond your product work and roadmap, which is already infinitely long, you have even more randomization through the many hats you need to wear. And still, you’ll only have a finite amount of time. The only answer to ensure your startup moves forward is ruthless prioritization.

Mitigating execution risk by getting the right things done first

Ruthless prioritization means focusing only on the most urgent items. Or rather, only those with a positive expected value compared to their cost in effort.

As effort increases, the value must increase exponentially to justify the same priority. My colleague Pierre shared this framework with a helpful visual, and even a mathematic equation: Priority = Value/Effort^2

In the context of startups, here’s why prioritization matters.

• When a feature lands matters. A feature value builds over time after it hits production. For this reason, the true value of several projects landing sooner can be greater than the sum of its parts. Take this example, landing 5 smaller projects in 2 months can have more value than one big project at the end of two months.

• Effort becomes harder to estimate the larger the scope, so we need to be more conservative as it increases. For example, if you estimate 1-day for a 2-day project, it's not a huge deal. If you estimate 3 months for a project that actually takes 6 months, that can be a huge miscalculation on prioritization.

• Smaller incremental iterations have a multiplicative effect on each other. This has been especially true for features with network effects like invites, sharing, and notifications.

While this tends to help identify the items in the green zone, it also has a dangerous side effect – important items or larger work items can get starved behind the day-week-long tasks that have an immediate impact. So how can you make progress on those items?

Priority inversion + Hackathons: How to get things done that are not a priority

Our approach? We run regular priority inversion weeks and to an extent, hackathons.

Priority inversion

We take priority inversion weeks periodically (roughly once a quarter) to ensure that items that are important but never urgent or as impactful still see the light of day.

I often find that when I’m given permission (or an excuse) to not focus on my primary projects, I’m able to methodically close out many long-standing tasks. Plus, you’ll find that keeping track of these items as you go, dedicating time to knocking them out, and marking them as complete is incredibly rewarding.

However, you can't operate in this mode forever. The high-priority tasks still need to be done. So timeboxing helps give you the right amount of space, while still getting back to urgent tasks quickly.

Hackathons

Once a quarter we run Hackathons, which I’ve found to be another great way to address this problem. If you’re frustrated enough that a feature hasn’t shipped –Hackathons are your chance to work on it! It can be in any domain, not even related to your current team.

We’ve shipped a number of hackathon projects that have a tremendous impact on our product. A few examples include:

• Statbot, AI helper in the console

• Sidecar, a no-code experimentation Chrome extension

• Performance improvements that loaded main pages in the console 30% faster

• Dev tooling improvements like speeding up tests by 50%

Balancing immediate needs with long-term goals

I used to get frustrated that the things I was excited about or that I saw would help resolve particular customer issues wouldn’t get prioritized. But the longer we’ve gone on, the more I’ve realized that we will get the right things done, in due time.

Sometimes what you have to prioritize is painfully obvious - like if payroll doesn’t get processed, you have to drop everything to make sure that happens. Other times, you need to choose one thing over another. It all boils down to what gets done first.

Learning what doesn’t work is part of the journey

As a startup founder, my default instinct is to just ship it. Move fast. Test, iterate, and learn.

This philosophy of iterative development has always been a core part of Statsig’s culture. From product and feature releases to our marketing moments, we run through quick cycles to learn from each experience. So when we decided to launch on Product Hunt, we followed the same principle: just ship it.

After watching other startups rank in the top 10 for the day, we assumed it was going to be easy…famous last words. Our first launch did OK, our second launch did not, but we think we figured it out for our third one.

Here’s what I learned across three Statsig Product Hunt launches, and the playbook I wish someone handed me.

Launch 1: Statsig (Day Rank #14)

It was back in August 2021, we had just onboarded our first cohort of customers and we wanted to have one of our first big marketing splashes. Product Hunt was an obvious choice since the social platform is dedicated to helping startups gain exposure. What wasn’t obvious was how their day ranking algorithm worked.

We decided to post in the morning with a long blurb and a few screenshots. But looking back, the first mistake we made was leaving the post alone for a good chunk of the day.

I did a few page refreshes and periodically checked on the launch. When I saw that we weren’t performing as well as we’d hoped, I reached out to friends and family to upvote our launch. But the initial momentum had died down already. By the end of the day, we ranked number 14.

At the time, I didn’t do much research, and I was a bit naive to think the upvotes would come organically. On a side note – one piece of advice I got was to include a bunch of emojis in my post, so that’s what I did. (I’m still unsure if this helped or hurt the upvotes 🤷🏻‍♂️.)

Overall, the experience taught me a lot, and I figured we’d rank higher on the next go.

Launch 2: Statsig Free Feature Management Platform (Day Rank #34)

In 2023, we made feature flags free to everyone. This was a huge announcement for us, and it was an update we wanted to share with other product builders. So we decided to launch on Product Hunt again.

This time, we did a lot more preparation. We created video assets and scheduled our launch for 12:01 AM PST to maximize our 24-hour voting period (we read this was the recommended approach). We also made an internal announcement to have employees be on standby, asking everyone to engage with the launch and respond to any comments.

Unfortunately, things didn’t go as planned. There was a bug (or a user error) that posted our launch earlier in the evening. No one on our side knew that we were live, and our launch sat on Product Hunt with little engagement.

By the time we noticed, it was too late for us. We didn’t have the initial momentum to push our post higher in the ranking algo. Lessons learned: triple-check the schedule/draft settings, and when in doubt, stay up until 12:01 am and ship the post yourself.

Launch 3: Session Replay (Day Rank #8)

Since our last launch, we’ve shipped several new products and features. One of our recent launches was Session Replay, which allows customers to see their products through the lens of their users. We felt this product would reach a new set of developers and founders, so we wanted to create a moment out of it on Product Hunt.

Here’s what our launch plan looked like.

The Product Hunt Playbook

1. Prep Work

   • Set a clear timeline preparation: We opted for two weeks of prep. We posted about the upcoming launch on Twitter and LinkedIn. We also created a “Coming Soon” on Product Hunt to build up the hype.

   • Gather visual assets and create engaging content: We added screenshots, created branded images, and recorded a short video showcasing the product.

   • Inform your team early on: We created a Workplace group chat called “The Hunters Game” where we sent periodic updates and reminders leading up to the launch. The Product Team was involved from day one.

2. Launch Strategy

   • Launch early to maximize exposure: As planned, we launched at 12:01 AM PST and made sure there was an early push of upvoters – which helped us hit the Feature Page.

   • Use email and social media to notify your audience throughout the day: We sent a launch email to our customers and made several social posts 11am – this helped keep the momentum of upvotes.

   • Engage with comments and monitor progress: After launching, I stayed up until 3 AM responding to comments and tracking progress. When I logged off, Matt, one of the engineers on the team, woke up early to cover the morning shift.

3. Post-launch Engagement

   • Encourage customers to leave comments and feedback: We asked our most engaged customers and some employees to leave comments to boost our ranking.

   • Reach out to active community members on LinkedIn: We reached out to developers and startups that we found on the “Coming Soon” page. The hope was to get these frequent users to engage with our post. It paid off with 10 responses and even a “Hunter” interested in our next launch.

A few resources we found helpful

1. Product Hunt Launch by Nick Costelloe

   1. This playbook highlights that Product Hunt isn’t a growth strategy but a PR event that can help you build traction for your product.

2. Product Hunt Launch Guide: Analyzed 15+ Successful Launches

   1. This guide analyses 15 successful launches and provides clear examples of tactical actions that successful “Makers” have done.

3. How to successfully launch on Product Hunt (when it’s right for your startup) by Leo Boseuner

   1. This newsletter includes interviews with the founder of Social Growth Labs who has helped over 160 companies hit the top 3 on Product Hunt and share tactical decisions.

What’s next for us?

Even though Product Hunt hasn't always been our most successful tactic, following this method helped us jump from #34 to #8 in daily rankings, triple our follower count, and snag the #2 spot for SaaS products of the week.

Hopefully, you will avoid making the same mistakes, and this launch plan will help you rank higher than we did.

When I wrapped up my first call with a new user, I stepped out of the conference room with a grin on my face. Feeling proud, I almost skipped back to my desk. But unexpectedly, I was stopped by a remark from the CEO.

“Well, that seemed like a disaster,” Vijaye said, from his desk. “Huh? It went well, they are going to try out our iOS SDK,” I replied.

From an outside observer, who couldn't hear everything but could sense just enough of how the meeting went, it was a disaster. And as I later reflected on the conversation, I realized it hadn’t gone well.

As an engineer, my default approach is to jump into the solution – review the product, highlight the features, and talk about our robust infrastructure. I assume the user knows what’s important and I’m simply here to point them in the right direction.

While any customer conversation is an opportunity to showcase your product, it’s also an opportunity to learn. And in the early days of a startup, learning is one of the most important things you can do.

First call retrospective

In hindsight, I made a number of mistakes on that call. For starters, I let the user drive the conversation – responding with what was on the top of my head, rather than diving into the why or the how behind their questions.

In fact, other than lightly probing them on their tech stack, and perhaps asking a single question about the problem, I didn't get a great picture of how Statsig fit into their overall system and the types of issues they needed help with. I also left not even knowing how they found out about us. Given it was so early in our history, I still regret not knowing how they found out about us. We’re significantly better at tracking these things now, but it didn’t really cross my mind to just ask that simple question.

Since that first call, I’ve taken countless meetings with new customers and remained involved in customer support and feedback through our Slack channel. Throughout these interactions, I learned how to avoid the same mistakes I made in that first call. Here are a few quick reminders on how to make the most out of those calls, emails, and Slack messages.

Tips and tricks for customer conversations

1. Conversations are a two-way street

Nearly every customer conversation (putting aside specific support requests), should not be one-sided. You aren’t there just for someone to ask you questions - you should be the one guiding the discussion, and the best way to do this is to ask questions.

2. You can walk away with more valuable insights by asking questions vs demoing your product

During the early days of your startup, it's easy to be distracted by the excitement of talking with a prospective customer. But to make the most out of the conversation, you should think beforehand about what you want to learn.

• What problems are they trying to solve?

• What is their timeline?

• What other solutions are they considering?

• Are there any key features that are dealbreakers for them?

The learning extends beyond just product discovery. You may not care right now, but you’ll eventually want to know how they find out about you. This may give you insights into where your target audience is and how you can market to them.

3. Always have a concrete follow-up

A good rule of thumb: don't end without a next step. Be sure to capture any follow-ups that are brought up during the conversation. If there are none, then have a natural touchpoint to check back in.

After that first call, I was lucky that the customer was motivated enough to install the iOS SDK and actually start using it. But I could have done more to ensure the likelihood of that, like following up with documentation. Even if I had not been that proactive, following up with an email once we noticed traffic coming from that customer to make sure they weren’t running into any problems.

4. Show your actual product

Just last week, I had the opportunity to be on the other side of this conversation, talking to a founder at another company about our needs, their product, and potential integrations. Walking out of that conversation, I realized I had no idea what the product was actually capable of. I was shown a mix of notion docs and Figma files - never the actual product itself.

Demonstrating what you can do today is far more important than your grand vision. Now, if I ask about something that is only in the design phase, by all means, show me what it will look like. Just don’t be wishy-washy about what you have now.

5. Bonus points: Combine 3 & 4 to delight and surprise your users

When possible, delivering an actual change to someone from something you talked about earlier that week (or better yet, earlier that day) can make someone a fan quicker than anything else.

The #buildinpublic movement is growing every day, and for a good reason. Involving your users and their feedback in what you choose to prioritize now, not later, is a delightful experience. Rather than showing a timeline, or mocks in Figma, whenever possible, deliver it now.

This motto of shipping fast has served Statsig well over the past few years, and we continue to respond in real time to customer feedback and suggestions. It made our product better, our engineering processes sharper, and our customers happier.

There are a number of other potential learnings I could share, or suggestions of things to improve your customer calls - these 5 have served me well so far. If you have any other tips, feel free to drop them in the comments below!

A common startup dilemma

A few weeks into Statsig, we encountered a dilemma most startups eventually face: do we buy a solution or build one ourselves?

During those early days, we were already missing the internal tools we used at Meta (Facebook). Despite building an alternative to Gatekeeper, which allowed Meta engineers to build features visible only to a targeted set of users, there were other tools that we wanted to replicate. But instead of taking the easier approach of buying an off-the-shelf solution right out of the gate, we defaulted to being scrappy.

However, we learned that this path works only sometimes…

When opting to build a solution goes wrong

Word Docs, Google Docs, or Notion?

When you’re just getting started, you don't need much more than a few email addresses. You’ll probably go to Google for Gmail or Microsoft for Outlook. The annoying (but potentially great) part about each of these Workspaces is that they come with a whole suite of tools for you to use – documents, spreadsheets, presentations, and cloud storage.

However, no matter which one you pick, if you achieve any sort of scale and start to hire a larger team, someone will eventually complain and want the other one. For us, we picked Microsoft 365 primarily because of Excel. Inevitably, someone asked for Google Docs.

After about a year, Word Docs and SharePoint weren’t working well for us. Organizing files under different teams and across the company became a challenge. In addition, collaboration tooling became even more important as we started hiring a remote sales team. All this frustration led us to clamor internally to use a tool like Notion. So what did we do?

Rather than go out and buy Notion, Vijaye first looked for open-source alternatives (classic Vijaye). He found Outline and set it up on our intern deployment, with a “d” shortcut to get to documents from our internal bunnyLOL. It worked at first, more because people were forced to use it than they enjoyed it. And then the feature requests started rolling in.

Why can’t I tag people? How do I make private documents? After enough pain points with no engineering team to support it, managing the deployment quickly became a nuisance that wasn’t worth maintaining. Begrudgingly, Vijaye paid for Notion, and we’ve been happily using it ever since. Lesson learned, just buy a tool to manage internal documents.

When building a solution goes right

The search for bunnyLOL

During the first week, one of the tools we missed the most was bunnyLOL (referenced above). It's a shared bookmarking service that can replace your default search engine. It makes it easy for groups of people to share shortcuts to the common tools they all use.

What we really wanted was to be able to type “lunch” into our address bar and have it take us to our Peachd order form for the day. So I whipped up a web controller on our intern deployment that could do just that.

Over time, we added to it. Instead of simple redirects, you can parameterize your commands. Typing “c <company_name>” will take you to a debugging view for a specific company. Or typing “google <serach_query>” will...take you to Bing?

While some people have used this shared bookmarking tool to troll their coworkers, others use the power for good. We even added a dynamic config in a Statsig project so anyone can easily add new commands.

Here are just some of the bunny commands we use regularly. And yes, we have a shared Spotify playlist.

Building an internal performance review tool

Over time, as we needed to provide a more formalized process for feedback and growth for individuals, we began running performance reviews for employees. Again, rather than buying an off-the-shelf tool to help with this, Vijaye opted to build our own.

We aren’t big enough for engineering teams to build and support these tools, but Vijaye enjoys building simple apps for one-off pain points we have. He whipped this particular one up over a dreary January weekend.

We’ve used it for a few performance cycles and it has made the process so much simpler. The alternative was managing Notion docs for 80 people with spreadsheets to request feedback. Instead, the tool aggregates information and manages feedback requests in one place.

Now that he’s built one that stuck, he found a framework that works well. So he cranked out a tool for managing interview loops as well. For the readers who work at Meta – look familiar?

Finding your alternatives to Big Tech tooling

As an early-stage startup, you can afford to spend time building things that are not core to your product. Yes, I know, this is a controversial take. But my advice is to pick and choose the battles you want to face.

To make your life a bit easier, we came across a few GitHub repos that list alternatives to the tech and services that Big Tech uses.

I wouldn’t recommend trying to recreate all the internal developer infrastructure that Meta or Google have, rather, if you encounter a problem you solved with a tool you used before, you might find something similar to replace it.

Ex-Meta (Facebook) List by Grzegorz Kowszewicz

Ex-Google List b John Huang

A peek into our tech stack

To add a bit of perspective, here are the tools we replaced from the ex-Facebook list. Just to call this out explicitly though, below is a snapshot of where we landed after three and a half years. For some of these tools, we went through a bunch of variations (as I mentioned above with the Notion). Hopefully, this gives you some direction on how you can replace the tools you missed at Big Tech.

Let me know in the comments below which tools you replaced and with what. Would love to hear how you solved the startup dilemma.

Happy tooling :)

Tore, Founding Engineer at Statsig

Big Tech → Startup → Clean Slate

Choosing your tech stack is one of the exciting bits of building a startup.

When working in Big Tech, you’re often forced to commit to an existing codebase and toolset. While the tight integration can offer comfort, it can also feel stifling at times. If you work at Meta (Facebook) for any period of time, you’re likely to end up writing some PHP hack, while your friends are off building with Next.js or Rust.

But when you finally break free from the cozy confines of a larger organization, you are also free from Mark Zuckerberg’s language choice in 2004.

Your tech stack isn’t permanent

Now I’m not here to tell you that you should only use Rust, or never use Node.js, or that you should definitely use Next.js, or trade HTMX for the hottest frontend trend…the list goes on and on.

Instead, my advice is much simpler. Don’t spend forever rabbit-holing on the perfect tech stack - pick something defensible, try it, and tweak it as you go. These decisions rarely last forever and are easier to change than you might think.

There’s a reason why people say “Premature optimization is the root of all evil.” Build until the cracks start to show, and then get creative about solutions. After all, your startup doesn’t need to handle infinite scale any time soon – it just needs to handle enough traffic to get your first customer on board.

To put this into perspective, here’s the story of how Statsig’s tech stack for event handling evolved..and why.

Shortcomings of our initial architecture

Before we started Statsig, we’d chat weekly about system design architecture, cloud providers, programming languages, and of course…coffee machines. (Okay, we mostly talked about which coffee machines to buy, and then went to play a game or two of DOTA).

One of the few things I remember aligning on was using the SMACK tech stack (Spark, Meso, Akka, Cassandra, Kafka) for our event ingestion and processing, which was all the rage at the time. But you won’t see this stack in our codebase today. Come to think of it, I can’t point to any other surface area in our product that has hit more scaling bottlenecks or that we have changed more over the past 3.5 years than our event processing stack.

Week one and reality strikes

During our first week, we set out to build event processing by our Node.js monolith server, using Kafka for event streaming and Cassandra as our storage layer, and then running our spark pipelines. Except we never even made it that far – we abandoned Kafka and Cassandra within the same week.

Instead, we started to batch-write files locally and then write CSVs to an Azure data lake. We also decided to use Databricks rather than raw Spark. We thought this was all we needed. In fact, our entire product strategy was captured on a whiteboard sketch. It was our illustration of the “wind of value” pushing developers to rain down events on the Statsig data pond 🤦🏻‍♂️…

One year in and we moved cloud providers

We quickly discovered that our ideal design wouldn’t work for streaming. We were doing batch processing but missing a few percent of total events. So we switched to Azure Event Hub, which improved reliability and enabled streaming into Databricks.

We later learned that using Databricks rather than our own Spark was the right call, but it wasn’t scaling for incredibly large datasets. Around January 2023, some of our larger daily jobs started…taking more than a day to run.

Fortunately, we tried out BigQuery and were shocked to find our 28-hour runs took just 4 hours - and they cost less! So we started the long slog of migrating all of our pipelines to GCP. But this change came with its own set of challenges.

Our workaround for data ingestion

At this point, we already had our Node app for ingesting events and logging to Event Hub. However, the new problem we faced was that our tight coupling of business logic to the persistence layer made things very fragile.

Changes or bugs in the processing code could lead to a worst-case scenario: event loss. So we introduced a lightweight event ingestion service (written in Rust) to blindly ingest logs and store them before processing them separately in the Node app.

In addition, we were still reading from Azure Event Hub after moving to GCP, so we were incurring a lot of costs simply from egressing events between cloud providers. Using GCP Pub/Sub would have been more expensive for our workloads, but we needed a first-party solution in Google Cloud to lower our cost.

Fortunately, we discovered a workaround. We wrote events to Google Cloud storage and used Pub/Sub to only pass the file pointer, so our processing logic could read the file and dump it into BigQuery.

Here’s a screenshot of the relevant bits from our high-level system architecture diagram:

We’re still not done scaling

And there you have it…nearly 3.5 years of evolution captured in this short blog.

From handling 0 events per day, to processing over 250,000,000,000 (and more)! We’re certainly not done changing our architecture to handle our increasing scale – but now we know how to improve it, piece by piece.

Let me know in the comments below which decisions or changes you’d like to hear more about, and we can cover them in more detail in a future post.

Happy scaling :)

Tore, Founding Engineer at Statsig

Welcome to Scaling Down, a newsletter written by the team at Statsig for engineers and product teams who made the leap from Big Tech to a startup.

Your journey meets our story

Behind every startup, there’s a story to share. For Statsig, our journey started with the belief that every product builder should have access to the same tools that Big Tech uses. Guided by this mission, we left Meta to join the startup scene.

Throughout our career at large tech companies, we relied on best-in-class internal tooling to power our fast-release cycles. But over time, through side projects and coffee chats with founders, we realized that most companies didn’t have access to the same caliber of tools.

This was especially apparent to us when we left to start Statsig. We were forced to build a tech stack and business from the ground up – without the infrastructure we took for granted.

The struggles we faced

We were also surprised by how few resources there were for product builders like us who took the same leap.

Early in our journey, we didn’t anticipate the series of challenges that existed outside of Big Tech. There were a lot of questions we didn’t know we needed to ask. Questions like:

• What should your first product growth dash look like?

• Where do you launch your product to get your first 100 users?

• Should you paywall up front, or offer a free tier?

• What technologies are people using nowadays?

Looking back at the early days, our struggles became the lessons we learned, and the advice we can share. (And trust me, we’re still learning more of them every day).

This is why we started writing this Substack: WE ARE on this startup journey, just like you, and we’re figuring things out together.

While we don’t claim to be the experts, we’re here to offer our guidance. From the questions we asked and answered (or those we wished we’d asked) to the product pivots we made, we’re sharing our perspective backed by our experience.

Written for engineers, by engineers

This Substack is the starter guide for engineers and product builders who made the leap from Big Tech to a startup. Whether you’re a solo technical founder, working with the founding team, or thinking of making that leap, this content covers:

• Guiding engineering principles from large companies refined for small teams

• Practical advice for everyday decisions and situations you may not have encountered while working in large companies

• The features and products other Big Tech founders have shipped and what they learned

To kick things off, here’s a behind-the-scenes look at how we landed on writing a Substack. Maybe this will inspire you to do the same.

Our journey to a SubStack

Do we publish on Medium or a self-hosted blog?

Deciding where to publish your content is one of the first questions you ask as a startup. And we were no different. Our content journey started in 2021 with a Medium blog.

Medium’s built-in content management system meant we could move fast, ship blogs, and focus on attracting our audience. But this approach came with its share of downsides: We gave up control over the look and feel of the articles for distribution and discovery. Medium already has a strong domain authority which helped our first few posts rank high in search. However, this forced us to make a few tradeoffs.

We learned that our Medium articles were cannibalizing our own site’s SEO and ranking. While our articles were getting a lot of views, which was great for content awareness, this wasn’t great for brand awareness and conversions. Very few users were flowing through to our actual website.

As a result, the user journey abruptly ended on Medium. So we ditched it altogether and started a self-hosted blog.

What value can we add through our content?

While reading other engineering newsletters and listening to podcasts, we realized there was very little content about leaving Big Tech for a startup. Since Statsig’s inception, we couldn’t find resources for product builders who left behind amazing internal tools to build them for others.

So we figured we’d document the learnings from our own journey, as we wish someone had done for us.

Why aren’t we publishing this content on our main blog?

After two years of running our blog (Peak Velocity), we learned that content creep is real. Over time, your blog starts housing content that serves different purposes:

• You write for discovery: Content that’s optimized for search and covers a wide range of relevant topics

• You write for product promotions: Content that’s product/ company-centric and guides readers to sign up or book a demo

• You write for the reader: Content that’s meant to educate the reader instead of driving leads

As more and more articles get published, each one competes for attention. While this might be a good problem to have, from the user's perspective, it makes it difficult to find highly impactful information. Specifically, content that’s meant to serve the reader (without the pitch) gets buried under the rest.

So we decided to separate this content from our blog entirely. This Substack is a space to reflect on what we’ve learned as we’ve “Scaled Down” from Big Tech to building our own startup.

Wrapping up

We made it clear from the beginning that this is not meant to drive leads. We will never charge for this content or gate it behind a form fill. While this content is about our startup experience, it’s not about our company. Instead, this content is meant to help you on your journey. Dive into what’s relevant and use it to take action.

We’re still learning along the way. So if you have any thoughts or there are topics you want us to cover, let us know in the comments below or by filling in the poll.

See you in the next post!

Tore, Founding Engineer at Statsig