Building at beehiiv

Hello again,

Since I started working in product at beehiiv, I’ve gotten tons of questions on how we ship so much, release a product update every week, and how we organize it all.

We release more in one quarter than entire companies do in years.

This newsletter is all about the proven experience from what I’m doing personally. This isn’t “best practices,” from a textbook. It’s what I do daily, per the questions.

Let’s get into it.

Where I’m Coming From

For context, our competitors release one product update every two-three months. Most of their updates are smaller. A product manager at Meta will (allegedly) write up 3-6 tickets (updates to the app) a week. We’ll do 30+ per week (per person).

We just completed 43 tickets today alone (tickets are a write-up, like a ‘blueprint,’ with details for what our engineers will build).

And our updates are massive. For example, in the last few months we’ve released:

• An AI to publish full podcasts or audio summaries from beehiiv posts (no need to record).

• Automated ads delivered to users directly (they don’t have to close their own deals).

• An entire store for our users to sell their own ads (if they don’t want ours) without separate payment systems or chasing invoices.

• An entire website builder.

• And dozens more I haven’t even mentioned.

So, how?

Absolute Chaos

While I’m writing tickets for three projects, our team is simultaneously designing eight more.

While that’s happening, another team is quality assurance (QA) testing the next release.

Five other teams work through our larger projects (we call them tentpole initiatives), which will be going live in three to five weeks while this is happening.

While this happens, we collect user feedback, scope and prioritize the quicker fixes, and our engineers finish dozens of these weekly.

This is what our typical month looks like. Again, most companies need 6-12 months for this much.

Here’s the punchline. We do this with just:

• Google Docs

• Linear (our project management tool)

• Communicating in Slack (similar to Microsoft Teams)

Staying on top if it is difficult. I don’t take every single thing, our team’s great about collaborating, but that’s the general summary. It’s chaos.

What Actually Happens

My job is to sit in the middle. I write up the details, organize the order our team would do it in, and pretty much stay on top of projects (I’m on of two product managers on the team).

Let’s get into the details.

Deciding what to build:

There are three large factors here:

• What the industry leaders are already doing or looking for.

  • In our industry, if the world’s largest newsletter has a sleek referral program, everyone else will want one too. If Arnold Schwarzenegger (a current customer), has a special automation, same idea.

• Customer feedback.

  • We listen closely to our customers. Many of our features are inspired by their feedback. We don’t build every single thing customers ask for, but we find the themes and prioritize accordingly. If even ten customers write in with the same awkward experience, chances are, we’ll fix it.

• The Industry.

  • If you want to be an expert on a product, you’ll have to be expert in the industry that product serves. Competitor research, trends, we watch it all and build accordingly.

Deciding How A Feature Should Work:

I look for a few key factors here.

• How someone else is solving the same problem.

  • There is no need to reinvent the wheel every time. Using other products in the industry (again, have to be an expert on the industry at large), is a great starting point.

• Doing it our (better) way.

  • Some companies use templates. They have custom requirements. Others force a series of steps to set something up.

  • There are several website builders out there. Ours is purpose-built based on what we know about our users wants and needs, and where the industry is going.

In summary: finding what solves the problem already, and then making it better (based on what your users need).

First Principles & Loops:

If I’m building something genuinely new, I break it down to the very basics:

• Desired outcome

• Fastest way to get there.

Then as you continue writing up how it works, you’ll find something new. Something you didn’t consider the first time. Every time you find something new, you add it to the scope, and make sure it’s still the fastest way to solve the problem (that’s the loop). I focus on speed for our users (aka “time to value”), because that works well for us.

This image is the best example I’ve ever found or First Principles and Loops. Notice how janky the first version is, and how much cleaner it is after they looped back to it over and over.

How to Know It’s ‘Right’

It’s hard to have confidence building for the first time. I struggled with this at first. How do you know users will like it? How do you know it’ll ‘work?’

This is why improving an existing solution is a good place to start (since people are already, successfully, using your starting point).

It comes down to something I’ve described before. Taste and ‘vibes.’

In software, most fast-growing companies list “taste” as a key qualification to join their team. It might feel random, but it all comes together.

• Taste is the ability to make decisions that create quality experiences.

Over time, you’ll build confidence. You’ll just look, and already know:

• Out of 100 things, which 3 really matter.

• If the solution really actually solves the problem or is more complicated than it’s worth.

• What to watch for that most people miss. The small things that come together for a wonderful user experience.

Trade-offs & Prioritizing (aka Tetris)

There are probably some colleagues of mine who secretly hate me for this.

See, you could always build more, add more functionality, or do more.

I take the opposite approach. I turn down a lot of ideas. Don’t get me wrong, I’ve literally told my colleagues “nobody wants to say no to building cool shit,” but it’s not always that simple.

Like I said earlier, we’ll have like 12 features moving simultaneously. Every extra thing on one project, delays all the others. Every update has to be focused entirely on the solution, and solve just for that. Too many delays if we branch out too far.

But there are also cases where you learn something new as you build. Something got missed, or something else changed somewhere. Now you have to add something. Then what?

There’s a good way and a bad way to do this.

We refer to it as Tetris, lining up all the priorities in a way that allows us to keep shipping product, without derailing the operation. Like the game, how you move things around when you can’t ship (or clear rows), right away, matters.

Organize resources poorly, and the Tetris game looks like a mess. Nothing gets done. Nothing gets shipped. Until…game over.

But when done well, it’s like art. Everything’s shuffled, but it’s still clean.

After a few incidents of trying to do too much too soon (maybe more than a few), I’ve learned the lesson. I hope you take it from me. We don’t need more.

Solve the problem, let the solution work, and only add something when there’s a new problem, or a new series of requests, or a new (hopefully big money) client demanding it.

Wrapping Up

Thanks again for reading. This was by no means everything, so let me know if you have any questions with a reply.

Now, a word from this week’s sponsor.