Always be shipping

In just the 26 months since we first launched beehiiv, we have quickly built a reputation for constantly shipping new features. But that was never our goal, it sort of happened out of necessity. 

Back in 2021 when we first entered the market…

• Substack had just raised a $65M Series B and was the clear leader in this new wave of newsletter-focused platforms.

• Twitter had just acquired Revue and began integrating it into their core product.

• Facebook had just launched Bulletin and made a splash with some huge celebrities and writers. 

• The existing email ecosystem was already remarkably crowded and competitive with players like Mailchimp, Active Campaign, Constant Contact, Ghost, Hubspot, and a few dozen others…

And there we were. Brand new, unproven, and offering a very limited set of features. 

• Automations? Nope.

• Subscriptions? Nope.

• Custom fields? Nope.

• Comments? Nope.

• Segments? Nope. 

• API? Nope.

Long story short — we had a lot of work to do. 

We needed to ship as many new features, as quickly as possible, to compete with the existing platforms. There was already a baseline foundation of what our target users expected in an email platform and we didn’t check half the boxes.

So how did we do it? Here’s the beehiiv playbook 👇🏽

1. Founding team of engineers 

2. Ship or die 

3. Unicorn engineers 

4. Engineering density 

5. Clear roadmap

6. Parallelize 

7. Tight feedback loops

8. Full transparency 

9. Progress >> perfection 

10. Mistakes are expected

Founding team of engineers

This one is probably the most intuitive, but also one of the most important in my opinion. Ben, Jake, and I all had an engineering background and came from a company that built very similar tech to what we had planned to build at beehiiv. 

The first 10 months consisted of nothing but coding. We learned a ton, developed robust processes, and really established the DNA of the company in these early days. 

It also was a safety blanket of sorts. As we began to scale the team, there was some comfort in knowing the nucleus of the team could always continue to ship features and push the company forward. 

Ship or die 

I alluded to this in the intro, but there was an immense amount of pressure to demonstrate that we could routinely ship new and worthwhile features. This came in two forms:

1. Attracting new users — without being able to offer X/Y/Z features, most potential users wouldn’t even look in our direction. It was a race to be able to ship what they wanted before we lost their attention.

2. Preventing existing users from churning — the moment we convinced someone foolish enough to use beehiiv, it was only a matter of time before they’d realize how much we were missing and began persistently sending me feature requests. This was another all out sprint to address these requests before they would churn.

I’d wakeup each morning to emails from dozens of our users asking for the same features, threatening to leave if we didn’t deliver. We lived in a constant state of fight or flight. 

That sense of urgency was baked into our lives from day one, and still exists to this day. It’s part of the company DNA. 

Unicorn engineers

We had the luxury of the first 4 people at the company being engineers (the 3 cofounders plus our CTO, Andrew)… so we could be extremely selective with who we extended offers to. There were a few qualities we deliberately looked for to optimize the performance and output of the team at our early stage…

• We only hired full stack engineers. Perhaps hiring specialty skillsets make sense at scale, but as an early stage company we needed someone to be able to own the frontend, backend, QA, and release all on their own. 

  • No waiting for the frontend team to finish their work or vice versa.

• Great sense of product and design. We didn’t have Product Managers or Designers. We didn’t have mockups or wireframes. We needed to hire engineers who had an intuitive sense for what made good UI/UX and could build it unassisted. 

• Understood the broader context of our users and business. Every engineer we hired was able to fully comprehend how what they were building would impact users and the business. They were never building in isolation, which led to better results and also increased urgency. 

• Passionate and results-driven. Debatably the most important, they were passionate about what we were building, writing excellent code, solving challenging problems, and were excited about the opportunity to be a part of a team like ours.

Engineering density

I believe we had an evergreen Software Engineer role up on our careers page for the first 18 months. We were always open to bringing on another talented engineer and we built the company as an engineering-first organization.

Today the tech team (consisting of engineering, product, design, and data) makes up over a third of the company. 

Clear roadmap 

If you include the 10 months of building beehiiv as a side project (prior to launching), we’ve been shipping code for 36 months. And there hasn’t been a moment where we didn’t have abundantly clear alignment as to what the next several initiatives were.

The roadmap is basically derived from three main sources:

1. Previous experience — my cofounders and I spent years building the internal tech and infrastructure at Morning Brew and know exactly what moved the needle in terms of content creation, growth, and monetization. 

2. Competitor offerings — the email space is incredibly crowded and there is already a pretty established baseline of features that exist in the market. We know where we’re winning and where we need improvement.

3. User feedback — we are constantly sourcing feedback from users and creating new tickets to address the needs of those who are already using the platform. 

Between those three inputs… we are constantly prioritizing and re-prioritizing initiatives, determining which engineer is best to own what, and then actioning them as quickly as possible. 

Parallelize 

As I alluded to earlier regarding full stack engineers… most engineers own features and projects entirely by themselves.

1. Write a technical scoping overview 

2. Get feedback from other engineers 

3. Write their own tickets for the project

4. Build the frontend and backend

5. Write tests and QA themselves

6. Get other engineers to review the code 

7. Request QA resources 

8. Ship and collect feedback

Because individual engineers can own this entire process end to end, we are constantly building at least a half dozen new features at any given time.

Tight feedback loops

• We have several direct integrations with social channels to pull in realtime feedback from users posting on social media.

• We have several workflows and processes to integrate the support team’s operations closely with product and engineering.

• We used to have every engineer directly answer support tickets for an hour or two each morning. 

• We tightly integrate feedback from our sales team regarding their prospect calls to our product team. 

• When users churn, we collect feedback about the product and surface those to the entire team.

Full transparency 

We hired a team full of remarkably smart engineers. It doesn’t make sense to have them operate in isolation from other aspects of the business. Rather, they are far more productive, creative, and in-tune to deliver exceptional results when they understand what’s working vs what’s not across the entire company. 

Often times the engineers are prioritizing a certain initiative due to external pressures… so being able to effectively communicate the importance of that helps to drive a shared sense of urgency.

Progress >> perfection 

Shipping something is (almost always) better than shipping nothing. Far too often teams find themselves working through a pretzel of hypotheticals or over-indexing on things they may incorrectly deem as important. 

While we can debate core functionality and edge cases for hours, ultimately the users will dictate what is valuable. And the best way to collect that feedback is to get it into their hands. 

We routinely ship features that aren’t entirely polished, and that’s ok. We always bake in time for fast follows to address user feedback, bugs, and other issues that arise after launching.

Mistakes are expected 

We’ve built a culture where mistakes are totally accepted, as long as we share them with the team and learn from them.

If you…

• are optimizing for speed to market

• only have a single engineer building each new feature

• adopt the philosophy that progress >> perfection

… then the trade-off is that mistakes are going to happen.

We probably ship a few more bugs than I’d like to admit, but we have dialed in the ability to…

• quickly collect real-time feedback from users

• flag production errors immediately from our reporting tools

• monitor usage and feedback via custom observability dashboards

More often than not, the bugs we do ship are usually addressed before most users even take notice. 

And of course, anything dealing with the flow of money or mission critical infrastructure is QA’d heavily across all of our environments and typically involves more than just the single engineer owning it.

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/always-be-shipping

Shoutout to Tola for our third reader submission. Giving big time Washington DC in the spring vibes.

Personally I prefer a window view behind my desk but I’ll take some funky modern art collage why not.

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…

• This thread of videos created by Sora is mesmerizing and I’ve never been so sure we’re all going to be out of a job in a few years (Twitter)

• Trump dropped the new “Never Surrender High-Tops” at Sneaker Con and the name rolls right off the tongue (AP News)

• What if software products had hardware? (LinkedIn)

• Mr. Beast dropped the “biggest announcement of his life” and it’s pure marketing genius. From shitting on Hershey, showing alleged blind taste tests, incentivizing purchases with cash giveaways, and making the whole thing entertaining.. it’s an absolute masterclass 👇🏽

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 🕺🏽