Vibe Building

And the need for speed.

Tyler Denk
April 22, 2025

There are two types of founders in this world: those who belong to Hampton… and those who don’t.

Hampton is a highly vetted membership community for high-growth founders. In fact, the founders behind some of the fastest growing startups in the world call Hampton home — recognize some of those names above?

Well, they could be a part of your private network. Benefits include:

Monthly core groups
Digital community
Member retreats
Speaker series
IRL meetups

Plus they’re launching IRL chapters in NYC and Austin with absurd talent density and tons of exclusive events. I’m currently lobbying to launch the LA chapter 🏄🏽.

Lucky for you — Big Desk Energy readers get to skip the waitlist.

I fucked up.

I recently realized that our incessant need for speed and doing more has led to a handful of blindspots and inefficiencies. We’ve been moving too quickly to stop and ask the important questions like:

What does success look like for this?
How do we measure it?
Who is going to own this?
How soon will we know if it’s working?

I’d argue that speed is a true competitive advantage as a startup, but speed backed by data can be an absolute superpower.

In retrospect, rather than using data we’ve been doing a whole lot of vibe building of late. Building things and launching new initiatives that feel productive without the proper measurement and accountability in place.

And now that I’ve seen it, I can’t unsee it. It’s everywhere, on every team.

I’ll start with using the product team as an example since that’s where I spend the most of my time.

We have created an absolute machine when it comes to churning out new products and features. From inception to launch, our team is exceptional at getting features to market.

…but that’s sort of where it ends.

We ship a shiny new feature then quickly pivot to the next highest priority and start the process all over again. It’s as if simply releasing the feature to the public was the final goal.

And to be fair — sometimes it is. Sometimes we promised to build something specific for a large enterprise user, and simply releasing it checks the box.

However in most cases, shipping a new feature is really just a means to an end. That end being the outputs that actually contribute to the growth of the company.

When you boil it down, there are three main reasons to build new features:

Expand addressable market. Launching new features allow you to serve users who you may not have previously been able to.
Generate revenue. In addition to serving more users, you can also put features behind a paid plan to increase revenue.
Reduce churn. By launching new features that solve your users’ problems, you can prevent them from leaving to explore other solutions.

That is to say — if shipping feature X will generate more revenue and reduce churn, then it’s likely worth pursuing. But simply shipping feature X and viewing that as an accomplishment in of itself is missing the forest for the trees.

In fact, we shouldn’t even commit to building feature X until we’ve clearly defined what success looks like in advance to justify the effort.

I’ll use a real world example to showcase this in action.

Last month we launched Direct Sponsorships. It allows publishers (i.e. newsletters) to manage their own sponsorship packages and book revenue directly with advertisers — all through the beehiiv platform.

It’s a killer product, and I use it to book and manage my ad inventory for Big Desk Energy (click to sponsor this newsletter).

How did it come about?

My cofounders and I built Morning Brew’s internal ads platform back in the day, which helped scale their sponsorship business to tens of millions in revenue. Lots of larger publishers on beehiiv sell sponsorships directly with advertisers (similar to Morning Brew), and had asked us to build an integrated solution.

We aligned on the vision, scoped the requirements, designed some mockups, then started building.

When we launched the product in March, we announced it to our users then simply moved onto the next project.

Was it a success? I honestly have no idea — we never defined what the success metrics were prior to building it.

Maybe you all are far smarter than I am and never fell into this trap. All I know is that that’s no way to run a business.

Rather, here’s what we should have done:

Set a success metric. Launch 10,000 storefronts in the first 60 days.
Justify building it. 10,000 storefronts correlates to roughly $500K MRR in expansion revenue.
Decide. Is the success metric realistic? If so, is the justification strong enough to build it?

Perhaps the answer is no, and you realize that there are higher upside opportunities elsewhere.

But if you do decide to proceed and build it — the product manager in charge should own the initiative through the completion of the success metric (launching 10,000 storefronts).

There is pre-launch product work (which our team is exceptional at), and post-launch product work (which we seemingly forgot existed). Post-launch product work requires thinking about product positioning, speaking to users, gathering feedback, iterating with engineers, creating new user journeys, and identifying opportunities to drive adoption.

In the above example — we justified building the product by having 10,000 people use it within the first 60 days, not simply for it to exist. We’re celebrating and optimizing for the wrong things.

Vibe building isn’t just isolated to product. I’ll pick on growth next because I also spend a lot of time there and am equally as guilty.

We launch a handful of new initiatives each week. All of them come from a good place: they are well thought out and perhaps have been successfully deployed by other companies.

But very rarely do we identify and align on the metrics that would make any of them a success prior to committing to them; we just default to doing. It’s fuck around and find out all the way down.

I’ll use our webinar initiative as a simple example. We host a handful of webinars each month, each of which require careful planning, preparation, and effort to deliver.

The ultimate goal of the webinar initiative is to drive new leads to beehiiv. The webinar itself is just a vehicle to accomplish that, but in reality there are thousands of ways to drive leads for the business.

Prior to committing, we should define exactly what we’d consider to be a success for any given initiative. Perhaps we justify the time and effort of the webinars by assuming each event will drive 100 new leads.

If after a few webinars, each event only drove 10 new leads, then we have a decision to make:

Whoever is owning the initiative needs to figure out how to 10x the output.
We take our learnings and move onto the next initiative.

On the other hand, if each of the first few events drive several hundred new leads, then that’s a strong signal to double down on the initiative.

Instead we mostly operate in the messy middle. We prioritize things that sound good in theory, rarely justify them in advance with real numbers, rarely measure the output, and rarely reassess the results against our assumptions.

I’m not saying that we don’t measure anything — of course we do. It’s just that I’m now realizing that our collective bias to action has led to some real blind spots.

Or at least, it did.

The dog days of vibe building are over — it’s time to build a god damn (data-driven) machine.

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/vibe-building

Credit: Kyle Briggs

Shoutout Kyle for the reader submission 🫡. This might be too close for comfort given the number of times I threaten to jump off a cliff during the day.

Good view though.

Think you can generate a better office? Reply with your submissions 📨.