The funny thing about ambitious launch dates is that they have a way of becoming approximate. Somebody says July, and July becomes late July, and late July becomes a soft launch to a beta group while the real thing slips to the fall, and everyone agrees this was always the plan 😂
On July 16, beehiiv launched Community on stage at their Summer Release Event, on the date that had been set months earlier, for a scope that everybody involved, us included, privately thought was ambitious when the schedule was written.
I want to talk about why this one held, because the answer is not talent and it is not heroics (although it is a little bit about culture). But for the most part, two structural things made it possible and both were decided long before anybody wrote production code.
What you’ll find in today’s issue:
- What a design phase actually buys you
- Why the cheapest place to be wrong is a Figma file
- The difference between an outsourced team and an embedded one
- What shipped
The engagement started as a design project
Since the dawn of time, before there was a build, there was a design phase.
In this case, the first week was not spent designing screens. It was spent translating beehiiv's existing visual language into community specific components. beehiiv had a mature design system already, so rather than run our usual sequence of low fidelity concepts followed by high fidelity work, we went system first and built the component vocabulary up front.
The effect of that is easy to miss, but had massive implications for the actual build. Every sprint after week zero produced work that was ready to build. We weren’t producing concepts that would need adapting, nor directional explorations that an engineer would have to interpret. What was getting shared was beehiiv-native, build ready design.
The reason the July date held is partly that engineering never spent a week waiting on a translation layer between pretty visuals and a real component.
This is your reminder to please, please - involve engineers early. It is always a good idea.
The cheapest place to be wrong
A saying our VP of Design uses quite often is that during design, time is cheap, but it gets expensive in development.
A practical example of that theoretical concept: during design, the team worked through the full spectrum of access models for the product. Read only. Preview. Fully gated. Space level. Metered. All of these were different approaches we could take, even if we knew we weren’t going to leverage all of them (especially at launch). In actuality, only two of them shipped in v1.
That theoretically looks like wasted time, but the reality is that exploring five models in a design file took days. Discovering in month four of a build that your access model cannot express what your largest customers need takes a quarter, and it takes it out of the middle of your schedule where you have the least room for any variation.
The other thing a definition phase buys, which nobody puts in a proposal because it sounds self serving and a little woo woo, is trust. beehiiv saw how we worked and how we handled their design language before there was ever a question of us touching their codebase. I do not think this project would have happened in the other order.
So here’s a good rule to keep in mind as you plan big projects: find the decision that would be most expensive to reverse, and make sure it gets made in the cheapest medium that can hold it.
Quite often, these are things like access models, permissions, pricing tiers, data models, etc. Probably anything with the word hierarchy in it. If one of these is currently scheduled to get resolved during a build, you’re planning on wasting money.
Then the engineers moved in (they brought snacks)
The second structural thing that materially impacted our ability to hit the launch date was how the build was run.
Our engineers did not work in a silo and chuck things over the fence, so to speak. They embedded with beehiiv's team. This means things like having a shared ticket pool, running daily standups, executing one week sprints with each engineer owning an epic end to end, and making architecture decisions jointly rather than proposed and approved.
The specific outcome of working that closely is that our people learned beehiiv's conventions well enough that a pull request read like it came from someone who had been there a year.
The objection to bringing in an outside team is completely reasonable, and it is often about velocity. Your own team slows down while the outsiders ramp. The cost of that objection is a real thing, but it also is a bit shortsighted. What embedding does is pay it once, at the front, rather than paying it again at every handoff for the life of the project - our experience has been that taking that approach pays huge dividends over the medium and long term.
And this is not really an argument about agencies, although I understand if it maybe comes across a bit self-serving. But the truth is that outsourced work optimizes for a clean handoff. Embedded work optimizes for there being nothing to hand off.
What actually shipped (after four newsletters)
The best way to experience beehiiv’s Community feature is to go sign up 😄 You can also check out their awesome launch video here.
But if you just want to read about it, here’s what we launched:
- A feed split between For You and Following
- Channels are seeded automatically from a publisher's newsletter and podcast, so nobody starts at an empty room (the cold start problem, solved by noticing they already had the content)
- Group and one to one messaging
- Highlight and comment on content
- Newsletter posts rendering inside Community with their own conversation attached
And the business outcome underneath the feature list is that when a beehiiv reader wants to talk to another beehiiv reader, they no longer leave for Discord to do it. The conversation stays where it started, which has massive benefits for the publisher’s entire business.
Three Thursdays ago I wrote the request was not the problem. The request was a community feature, but the problem was that the most engaged readers on the platform were being exported to somebody else's product every time they wanted to talk.
Now that Community is live, that is the thing that got fixed, and you can draw a straight line from the eight questions in December to a launch date in July that did not move (or go re-read my last few newsletters to refresh yourself).
If you’d like me to do this type of deep dive on another one of our projects, let me know! It was pretty fun pulling apart a big piece of work like this, so if it was valuable I’d be down to do it again!
