shipOS

At beehiiv, we ship a handful of new features each week. It’s probably what we are best known for in the startup community.

Today I’m going to share the processes, philosophies, and frameworks we utilize to accomplish this.

But first, I’ll start with some context…

This has truly been our DNA and playbook from day one. Both of my cofounders and I are engineers. When we began building beehiiv as a side project back in 2020, there was nothing to do but to write code and ship. We weren’t wasting time on financial models, marketing strategies, etc.

To paint a broader picture of the competitive landscape at the time…

• Substack had just raised a $65M Series B at a $650M valuation.

• Facebook had just launched Bulletin, their paid newsletter product.

• Twitter had just acquired Revue, an Amsterdam-based newsletter product.

• Oh, and there were dozens of already successful incumbents like Mailchimp, ActiveCampaign, AWeber, MailerLite, etc.

While those companies had millions in funding, large established teams, and thousands of paying customers… my cofounders and I were moonlighting this project on nights and weekends.

It’s so difficult to describe the anxiety of those pre-launch days. Yes, we had conviction… but our conviction was that we could compete in the market as it was. With each passing day our competitors were deploying capital and launching new features while we were at risk of being left behind.

Only one truly thing mattered: getting to market as quickly as humanly possible.

There really was no alternative option. Anything less than ferociously shipping code put us at risk of missing this window of opportunity to launch something that we believed had a fighting chance to succeed.

By the summer of 2021, we had a somewhat functional prototype. It was far from impressive, but it gave us what we needed to accomplish two things:

1. Get it in users hands to collect real feedback.

2. Raise a small seed round so we could go full-time and hire others.

Reid Hoffman, founder of LinkedIn, famously penned the quote “if you are not embarrassed by the first version of your product, you’ve launched too late.” And I couldn’t agree more.

Our first version of the product was rough. Very rough. But it didn’t matter — I just wanted people to use it and tell me what sucked about it so we could iterate and address their feedback.

I think a lot of founders are scared of criticism. The truth is, if your company is going to be successful, the users who encounter your product in the first few months are such a tiny fraction of all future users. I’d rather our first 10 users tell me why our product blows so I can fix it prior to onboarding the next 10,000.

Giving access to a few dozen beta users was the greatest shortcut we ever discovered.

At this point, two core philosophies had already been ingrained deep into the company DNA and ethos:

1. Ship or die. The only way to survive in this competitive landscape was to consistently ship new features that provided value to our users.

2. Speed over perfection. Optimize for the tightest feedback loops possible. Perfection delays feedback while also killing momentum and velocity.

We formally launched beehiiv in November 2021.

According to my monthly investor update (which you can read here), we had a bit of initial traction out of the gate… but it was apparent that we still had a tremendous amount of work to do.

Translation: our product was by far the worst in the industry.

Granted, that was sort of to be expected. Most of our competitors had launched nearly a decade earlier, and we were the new kids on the block. We had no automations, no segmentation, no subscriber tags, no custom fields, no analytics, no website layouts, nada.

With so much to build, I created a pretty simple framework to help triage and prioritize these initiatives. Ultimately, our product roadmap was derived from…

1. Our experience at Morning Brew. One of the core theses of beehiiv was that my cofounders and I had already built the internal tech and infrastructure that helped scale Morning Brew to over 3 million readers. We already had a proven playbook, knew what to prioritize, and understood first-hand what newsletters needed to succeed.

2. Preventing current users from churning. If a user threatened to churn because we were missing something, we immediately prioritized that feature.

3. Unblocking potential new users. If someone wanted to move to beehiiv but was blocked because we were missing something, we immediately prioritized that as well.

4. Counter-positioning competitors. Whenever other users would complain about the inability to do something on a competing platform, we would prioritize building something to serve them.

5. Direct user feedback. Whether from our support tickets, posts on social media, or elsewhere… any time existing users complained or asked for something, we took notice. After hearing the same request a few times, we’d prioritize it on the roadmap.

This is more or less the same framework we still use today.

And as you could imagine, the result is a list long enough to make your head spin. It takes several rounds of prioritizing, re-prioritizing, cutting and shuffling, to ultimately land on a handful of tentpole initiatives. The goal is to narrow the focus down to just what is going to be built during the upcoming quarter.

Sure, I have plenty of ideas regarding what I think we’ll build in future quarters, and obviously some initiatives take longer than a single quarter… but priorities shift, market dynamics change, and certainties become uncertain. I only ever plan for a quarter at a time.

I take the finalists and convert them into a list in a fresh Google Doc. Below the fold I expand on each of them in considerably more detail — use cases, project owners, timelines, relevant docs, etc.

Once the doc is complete, I send it to the entire company to review and leave comments. The purpose is to gather feedback and stress test these initiatives with the broader team to ensure we are prioritizing the correct things, in the correct order, and making the appropriate trade-offs.

After giving everyone a few days to review the doc asynchronously, I lead a company-wide product roadmap session where I address the comments and questions in real-time. The goal of the meeting is to make adjustments if necessary, find alignment, and solidify the roadmap.

The unfortunate reality is that at any given time, more things will be deprioritized than prioritized. That’s the nature of the beast, and some teams may feel slighted. But your job as CEO is to acknowledge the trade-offs and prioritize what optimizes your chances of success, not to make everyone happy.

Once the quarterly roadmap is finalized, we create a unique project for each “epic” (i.e. initiative) in Linear. Linear is the project management software tool we use for engineering and design, and I absolutely love it. No, I’m not getting paid to say that… but if anyone from Linear is reading this hit me up for sponsorship opportunities.

Now we get to my favorite part — 3D chess… or so it feels that way. There’s some beautiful and delicate balance in aligning the dozens of priorities and timing of it all to ensure optimal efficiency and outcome.

• Some features are blocked by others.

• Certain initiatives must be built in some pragmatic order.

• Sometimes the engineers best suited to lead something are busy with other tasks.

• Priorities are constantly fluctuating in real-time.

• Plus there’s always a handful of uncertainties, fires, sick days, etc.

It’s just a never-ending game of blocking and tackling as we shift bandwidth between a handful of different projects in parallel. All while I’m trying to coordinate these launches to happen at just the right time to optimize their reach and impact.

Finally, to land this plane we need to get technical for a moment. We follow what most people refer to as agile development, and scrum to be specific.

Sprints allow us to break up a somewhat-overbearing quarterly roadmap into smaller bite-sized pieces that are easier to digest and track. Again, tighter feedback loops help to hold everyone accountable and ensure we’re making progress in an efficient manner.

We ran 2-week sprint cycles for the first 2 years, but began to realize a few things…

1. Almost none of our epics were ever able to be completed in a single sprint, so we would drag these half finished projects from one sprint to the next.

2. In theory we should be adding tickets to each sprint to address bugs, tech-debt, and other engineering-led initiatives… but in practice we rarely ever did.

3. Because of that, there was a growing rift between me, leading product, and our CTO who wanted to address the above.

So earlier this year, we kicked off 3-week sprints and 1-week cooldowns:

• The 3-week sprints are what you’d expect.

• The 1-week cooldown is where we shift almost all of our engineering resources to address bugs, tech-debt, performance issues, quality-of-life improvements, etc.

This new framework ensures we never go more than a month without addressing those types of engineering-led initiatives, while being able to confidently prioritize feature development during the sprints. Overall, it’s allowed us to move much more quickly and clean up a lot of the tech-debt and bugs that we had previously ignored.

From survival to cooldowns… we’ve come a long way but are still sprinting as fast as ever 🏃🏾‍♂️💨.

If you enjoyed this post or know someone who may find it useful, please share it with them and encourage them to subscribe: mail.bigdeskenergy.com/p/shipos

• I’m hosting 7 other founders (or early startup employees) on a beautiful beachfront compound in Tamarindo, Costa Rica.

• Comes all-inclusive with private chefs, transportation, activities (like surfing, yoga, massages, etc.).

• Everyone will have their own private villa and bathrooms.

• This is my second time hosting this event. The first was so epic and I have lots of ideas to make this one twice as impactful ✌🏽.

Dates: Wednesday October 23rd to Sunday October 27th
Location: Tamarindo, Costa Rica
Cost: $12,500

Applications close this Friday. I’m not an accountant, but have been told this can be written off as a business expense 😉.

Shoutout to Ari for the reader submission. I can’t decide if this office would wildly motivate and inspire me… or distract me from ever getting anything done 🏄‍♂️.

Reply with your own AI generated office and I’ll feature it in an upcoming issue.

Turn on, tune in, drop out. Click on any of the tracks below to get in a groove — each selected from the full Big Desk Energy playlist.

Some of my favorite content I found on the internet this week…

• Bryan Johnson claims he achieved 8 months of perfect, 100% sleep… and shared how (Twitter)

• What does a Chief of Staff do and how to hire one (Bay Area Times)

• 10 lessons Noah Kagan, employee #30 at Facebook, learned from working directly under Mark Zuckerberg (Twitter)

• Ben Thompson breaks down the Google antitrust case better than anyone else (Stratechery)

Share this newsletter with your friends, colleagues, and cute girls.

1 REFERRAL = 25% OFF EVERYTHING IN THE STORE

Your referral count: 0 

Or share your personal link with others: https://mail.bigdeskenergy.com/subscribe?ref=PLACEHOLDER

Enjoyed this newsletter? Forward it to a friend and have them signup here.

Until next Tuesday 🕺🏽