A few weeks back I outlined some of my learnings from working at beehiiv. The feedback was great but there were some requests for more detail and first-hand experiences… so here goes Part 2.
The gist of the learnings from Part 1 was that if you bring developers in early in the scoping process and make sure that your MVP has some ‘magic’ then you can consistently deliver high-quality features, and this effectively becomes your growth strategy. (You can read the full article here).
The real questions, though, are how you identify the magic, how you prioritise what to build, how you build the right developer experience to enable the velocity & how you get the most out of your product team.
That’s what we’ll cover here:
#1 Access to your customers = superpower
Your ability as a Product Manager to move fast is largely determined by how quickly you can build confidence in your assumptions around what to build (and why). The easiest way to do this is by deeply understanding your customer.
Most companies struggle to get users on the phone/email or limit customer research to sporadic ‘sprints’ once per quarter.
At beehiiv, we do this differently. Here, interacting with customers is an always-on activity, with PMs interacting with 30-50 customers per week across slack/email/calls.
This all starts with out slack set up:
#community-website-builder & #community-feedback : Two Slack channels, each with 5k+ users, giving us feedback on different parts of the Beehiiv platform.
#[Agency-channels]: Where we work closely with multiple agency partners that use beehiiv to provide newsletter and website services to their clients
#topic-feedback - Internal feedback from the 30+ newsletters and websites that are run personally by the beehiiv team.
#Bot-feedback & #bot-bugs: A constant stream in slack of in-product surveys delivering feedback, user insights and highlighting areas of friction/missing functionality in the product
For new product development, this setup is a superpower. It gives me constant visibility into what users want, lets us test new ideas within minutes, and ensures every feature has enough “magic” before launch.
It’s also the fastest way to build product intuition—because everyone, not just the product team, stays connected to what customers are feeling.
When customer feedback is this accessible, every decision starts from real user insight, not assumptions.
Key takeaway: Find a way of removing the friction between you and your users to put customer interactions on autopilot.
#2 Balancing short vs long term prioritisation
A classic challenge for leadership and product teams is deciding whether to prioritise short-term customer wins or long-term initiatives that strengthen the business.
If you want to grow loyalty and word-of-mouth, getting wins on the board for customers is a non-negotiable. Loyalty comes from trust, and trust comes from delivering features consistently.
These are small, non-critical feature requests your power users love.
However, like every feature, these require brain space, planning and resourcing across product, engineering and design. Often, this is directly at odds with the long-term play.
Like most Product Managers, as I’ve progressed in my career, I’ve shifted more and more towards the long-term / “how we win” view of prioritisation. However with beehiiv I’ve re-adjusted my approach to foster loyalty and drive growth in the short term, whilst also unlocking long-term opportunities for the business.
My new hybrid approach :
Short term Initiatives (25%)
Include at least 1 small customer win each week
This are either reactive to feature requests/feedback or are just being pulled from the backlog
Long term initiatives (75%)
Create a clear long-term vision of what features/products need to exist for us to win in the market
Chunk that vision into ‘phases’ to create building blocks of work.
Map each building block to a significant customer win (even if it means expanding scope slightly)
This hybrid approach keeps our momentum high without losing sight of the bigger picture. It ensures we’re always shipping visible improvements while quietly building the foundation for long-term success.
#3 The power of a technical founding team
The common story of every product manager at an early stage startup is the battle of speed vs tech debt. Ie do we rush this through and cut a few corners (speed) , accepting that doing so will make life more difficult in the future due to fragile infrastructure and mounting technical debt?
In every business I’ve been a part of so far, the decision from up-high is always to prioritise speed, with the note that “we’ll fix it later". However, this almost never happens as the allure of adding another new feature is simply too tempting compared to going back and solving tech debt.
Unsurprisingly this compounds over time and velocity slows to a crawl as new code unexpectedly breaks other parts of the system, engineers lose confidence in the codebase and you’re forced to reactively rebuild some parts of the app.
Suddenly even tiny changes take days instead of minutes.
One of the primary causes of the above situation is engineering not having enough of a voice at a leadership level. This is especially true when the founding team is non-technical - it takes time to bring in a CTO and even then they are often forced to compromise to deliver the short term business objectives.
Which brings me to beehiiv: the founding team was made up of four engineers (even Tyler used to code). This is so evident in the culture and the ways of working:
Every month there is a dedicated ‘cooldown’ sprint where engineers can go back and clear up/extend/strengthen work done during the previous sprint
Engineers are able to shape scope and timeline, often expanding scope slightly to enable future functionality and speed
Engineers are willing (and encouraged) to speak up and are trusted to be proactive and come up with suggestions when it comes to improving UX through the flow
All of our most senior engineers have been there since pretty much day one, meaning they have an incredibly in-depth knowledge about how everything was written and know where the weaknesses are
What is the impact of this?
Engineering estimates are remarkably accurate
I’m consistently amazed by how fast the engineers are not only able to make small changes but also build entirely new features.
The system is robust with very few critical bugs
The product team (and business) can have faith in their ability to deliver against roadmap
Key takeaway: A technical co-founder doesn’t just enable you to move faster - they build the systems and culture that make speed sustainable.
#4 Give your product teams license to focus.
If you want to get more out of your product teams, give them permission to focus. Let me explain….
Throughout my product career working in product I’ve always been tasked with building, monitoring & improving multiple initiatives simultaneously - “build a great product”, “add new features”, “improve activation”, “improve website conversion”, “reduce churn” etc etc etc.
In theory, the benefit of this approach is that it gives the PM flexibility to identify and switch to the area that needs the most attention and has the biggest impact on revenue.
The downside of this approach (in my experience) is that
Leadership are rarely willing to stay the course and if any other metrics are underperforming you usually end up having to split your resources and tackle the other area
Certain metrics (onboarding / activation / signup:paid) always end up getting prioritized by leadership over improving the actual product. This has several knock on effects, but the TLDR is usually a stagnant product, less differentiation, and slower growth.
Here’s how this cycle usually plays out:
You’re focusing on building a key set of improvements to the product
Marketing increase investment in paid acquisition
As paid scales it drives lower quality leads → conversion rate falls
Conversion rate falls → CAC increases → unit economic worsen
Reaction: “We need to solve the funnel so we can get paid to work”
PMs and engineering get pulled away for new feature work to prioritize activation.
After a few months your product hasn’t improved in months, competitors have caught up → paid acquisition gets harder
Repeate the cycle
This isn’t how we do it at Beehiiv.
From day one, we agreed that the most important thing I could work on in my first 180 days was the Winter Release Event (next week).
That meant my only focus would be building new products, specifically the website builder and the features launching as part of the release.
Even if website conversion or adoption metrics were to dip temporarily, my priorities wouldn’t change. Why? Because the team trusts that the only way to deliver the Winter Release is through unwavering focus.
Having that level of focus is rare, but it’s powerful. Knowing you’re allowed to finish what you set out to do keeps product and engineering aligned, removes distractions, and helps velocity compound over time.
Key takeaway: The fastest way to move faster isn’t adding more priorities, it’s sticking to them.
Thanks,
Jake
Author, Release Notes
PS. If you’re considering launching a newsletter and want to get 20% off beehiiv you can use this link.
As a PM, one of the biggest challenges at the moment is keeping up with AI. The most effective method I’ve introduced to make sure I’m up to speed is reading the daily update from AI report.
It’s easy-to-digest and gives you just the right amount of technical detail to have a conversation with your engineers, but not so much to make you switch off. Give it a try today!
Built for Managers, Not Engineers
AI isn’t just for developers. The AI Report gives business leaders daily, practical insights you can apply to ops, sales, marketing, and strategy.
No tech jargon. No wasted time. Just actionable tools to help you lead smarter.
Start where it counts.