Always Be Shipping

What's up, everyone? Welcome back to another episode of Founders Journal. I'm your host, Alex Lieberman, co-founder and executive chairman of Morning Brew. On Founders Journal, I act as your startup Sherpa, finding the best content on the internet, reading it so you don't have to, and sharing the best insights so you can actually action on it within your business. On today's episode, I am going to share a recent blog post by Tyler Denk, who is a close friend a former employee of Morning Brew, and most importantly, the co-founder and CEO of Beehive, which has been absolutely crushing it. On this episode, I'm going to be sharing his thoughts on how Beehive has built a reputation of shipping features constantly and what it looks like to build a world-class engineering org. So let's hop into it. Always be shipping. How Beehive built a reputation of constantly shipping features by Tyler Dink. Now, before I hop into this post, I just want to say I love reading posts like this because as a non-technical founder, I find it super helpful to understand how engineering orgs work so that I can learn how to better work with engineers and product people, but also I think there ends up being a lot of abstractable lessons in the way that engineering and product organizations work that you can apply to other areas of business. So let's hop into it. Always be shipping. In just the 26 months since we first launched Beehive, we've 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 $65 million 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, ActiveCampaign, 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 is the Beehive 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 is greater than perfection. And 10, mistakes are expected. Now, I'm going to go through each of these 10 parts of the playbook in a second. But what I just want to share here that I think is an interesting observation is it's really interesting to think how Beehive has built such incredible momentum. I think I saw Tyler mention yesterday, the day before recording this episode, that Beehive is about to get to $10 million in ARR. And And that's just in 26 months. So just over 2 years. And it's kind of crazy to think about where he, you know, admittedly is playing in an incredibly crowded space, right? Like the email platform space is super crowded. And so then it begs the question, in the world of software, how do you win when you're playing in such a crowded space? And it sounds like, at least from what he has said, that having the same features as other platforms, like reaching feature parity, is table stakes. Like that is just something you need to do as quickly as possible as a platform in a crowded B2B SaaS niche such that people are willing to take you seriously and are willing to use your product. And so what's interesting to think about here is if that's table stakes, what are the things that actually make people choose Beehive over Mailchimp, ActiveCampaign, you know, ConvertKit, Review— well, Review is shut down, but Substack, all these other platforms. And so as I go through these different parts of the playbook, I'm going to try to pull out areas where I actually think differentiation happens because it seems like differentiation does not happen at the product feature level. Okay, let's keep it going. 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 Beehive. At Beehive, I'm going to say that one more time. 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 Beehive. 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 was also a safety blanket of sorts. As we began to scale the team, there was some comfort in knowing that The nucleus of the team could always continue to ship features and push the company forward. Something I just want to add here that's just a fun anecdote is I remember the first time that Tyler came to Austin and I because Tyler was employee number three or four at Morning Brew, and he had been building all of our internal tools at the company. So the CMS that we use to create and schedule Morning Brew newsletters every day, our internal tool that the sales team used to handle advertising copy and collaborate. Collaborate with the brand partners we were working with. And I remember Tyler came to us and he was like, guys, I think there's a lot of demand. Like, we could productize the tools that we're building internally. And I remember Austin and I being like, yeah, it's an interesting idea, but you know, we're going to keep focused on this media thing. And you know, a few years later, Tyler went off and did this, and he built it into Beehive. And one, I couldn't be more proud of him, but I think there's a few other really important lessons. The first is that some of the best business ideas you just find from creating internal tools in a company. So I just have this belief that like at some of the fastest growing companies right now, whether it's Stripe or Shopify or Amazon, there are so many internal tools being used at these companies, at these high growth companies that are probably 9-figure to 10-figure businesses on their own. Like you even think about Amazon, AWS was effectively an internal infrastructure where Amazon.com was the first customer and then it was turned into a productized offering for other people. So that's the first is internal tools at fast growth companies are oftentimes great products that could be separate companies on their own. And Beehive is an example of that. The second thing I'll just say is that Tyler is like the perfect example of what I look for in early employees in a company, which is to me the first 10 employees in a startup. You should be able to look at them and say to yourself, I think this person will do incredible work for us for a number of years, but ultimately I could see them starting a company of their own. And I think Tyler is like the quintessential example of that. Okay, let's keep it going. 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 2 forms. One, 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. And 2, preventing existing users from churning. The moment we convinced someone foolish enough to use Beehive, 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 wake up 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. I think this culture of discomfort, this culture of kind of like a deep paranoia that if you don't move fast enough, your customers will leave you, is actually a very healthy level of paranoia that companies should have. And if they lose that, they should actually start getting worried. Unicorn engineers. We had the luxury of the first 4 people at the company being engineers, the 3 co-founders 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. And by the way, I find this very interesting because hiring engineers is not something that I at all have experience with. He says we only hired full-stack engineers. Perhaps hiring specialty skill sets makes sense at scale, but as an early-stage company, we needed someone to be able to own the front end, back end, QA, and release all on their own. No waiting for the frontend team to finish their work or vice versa. Second, 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. Third, 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. What I'll also just add there, by the way, is for early employees, I think one of the greatest things for them is feeling like they understand multiple parts of the business outside of just what their JD is. So I think one of the best retention mechanisms and honestly, like momentum and culture builders as an entrepreneur in the early days is to share as much as possible. The more that you make people feel like owners, and one of the best ways to make them feel like an owner is giving them as much information as an owner has. I think the more they will stay motivated and excited Excited about the business, and then the fourth thing about hiring engineers that Taylor shares: 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 part of a team like ours. Next, engineering density. I believe we had an evergreen software engineer roll 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. Something I'll just share here is I do think for like every company has its core competency, and for its core competency, it has one role that is most important to deliver on that core competency. At Beehive, it's a full-stack engineer. At Morning Brew, it is— it was a newsletter writer. Now it's, you know, writer or creator. At StoryYard, my personal branding business, it is writers. And so similar to how Tyler just had kind of this evergreen engineer role up on his career page, we just have an evergreen copywriter role on our career page for StoryYard because you are really looking for unicorns, especially in the early days, for kind of the core role that defines your core competency. And it requires kind of always having your ear to the ground of the market to find a unicorn that shows up once every few months and you, you need to kind of always be in market for that to happen. Next, clear roadmap. If you include the 10 months of building Beehive as a side project prior to launching, we have 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 3 main sources. Previous experience. My co-founders 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 2, competitor offerings. The email space is incredibly crowded and there's already a pretty established baseline of features that exist in the market. We know where we're winning and where we need improvement. And 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 3 inputs, we are constantly prioritizing and reprioritizing initiatives, determining which engineer is best to own what, and then actioning them as quickly as possible. The next is parallelize. That is a very cool word. I've never used that word. Parallelize. As I alluded to earlier regarding full-stack engineers, most engineers own features and projects entirely by themselves. 1, they write a technical scoping overview. 2, they get feedback from other engineers. 3, they write their own tickets for the project. 4, they build the front end and back end. 5, they write tests and QA themselves. 6, they get other engineers to review the code. 7, they 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 real-time feedback from users posting on social media. By the way, one thing I'll share about social media is similarly to how in the early days of Morning Brew, we would reply to every Morning Brew reader who emailed into our team inbox. Tyler has done an incredible job of on social replying to anyone who talks about Beehive, whether it's a nice thing or whether it's about feedback about the platform. It feels like he is everywhere talking to his customers. Number 2, we have several workflows and processes to integrate the support team's operations closely with product and engineering. 3, we used to have every engineer directly answer support tickets for an hour or 2 each morning. 4, we tightly integrate feedback from our sales team regarding their prospect calls to our product team. 5, 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 versus what's not working across the entire company. Oftentimes the engineers are prioritizing a certain initial initiative due to external pressures. So being able to effectively communicate the importance of that helps to drive a shared sense of urgency. Progress is greater than 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 is okay. We always bake in time for fast follows to address user feedback, bugs, and other issues that arise after launching. Now, one thing I'll just also share here about progress and about the fact that Beehive ships constantly is they tie their product and their speed of shipping to having a really genius marketing strategy. The way I would describe Beehive marketing is they've kind of taken the drop-style marketing that fashion brands like Supreme have done over the years, and they brought it to B2B. What they've basically done is because they know their product roadmap going out, let's say a quarter, and they have some new product update or release every 2 weeks, they have now this standardized blitz package that they do every 2 weeks to create buzz, like this ongoing noise around Beehive. So every 2 weeks you'll see a tweet and a blog post from Tyler. You'll see every Beehive employee talking about the new feature. They have an in-house video creator who creates a short-form video about the product update. So they have this kind of like noise machine that is turned on every 2 weeks that runs in parallel with their product roadmap. And I think it's absolutely genius. And I think more companies need to adopt the Supreme-style drop-esque marketing strategy for non-fashion businesses. And then the final section: 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, and adopt the philosophy that progress is greater than perfection, then the tradeoff is that the 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, and 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. And so that is Always Be Shipping by Tyler Denk. Before we go, I just want to say I'm so incredibly proud of what Tyler's done. It's amazing to be a small part of his journey as an entrepreneur and just see Beehive absolutely take off. And I think this read is not just great for technical founders or engineering leaders. It's great for anyone who wants to be able to empathize with a product or engineering org and also think about how there are lessons that you can take from the way that engineers work and apply it to other areas of business. With that, thank you so much for listening to Founders Journal, and I'll catch you next episode.