Dock's Product Launch Playbook: Lessons from 50+ product launches

Why we soft-launch features before announcing them, plan the marketing before we build the product, and don’t believe in a public roadmap

After four years of working together, Alex and I have developed a pretty tight product launch playbook for Dock. 

We've done this 50+ times now—some launches are small (a new button, a workflow improvement), others are massive (like our learning management system, which we just launched). 

But the launch process, from ideation to marketing release, is largely the same every time, and we've refined it to the point where everything is quick and repeatable.

A lot of what we do goes against conventional marketing wisdom. There's a popular sentiment that "nobody cares about your product" and that you should never lead with features. But product launches have consistently been one of our best-performing marketing and sales channels. 

We ship something new almost every week, we announce it publicly every time, people actually engage with it, and our prospects notice.

We’ve developed some non-standard practices along the way that really work for us: We soft-launch products weeks before we tell anyone about them. We start building marketing messaging before the product is even done. And we've completely abandoned the idea of a public roadmap.

Here's a deep dive into Dock’s product launch playbook, with lessons you can steal for your startup.

Growth Bytes

Top takeaways:

• Plan the marketing messaging before you build the product. Like Amazon's "working backwards" method, starting with messaging forces clarity on what you're building and why it matters.
• Launch the product before you launch the marketing. Soft-launching 2–3 weeks early gives you time to find bugs, gather customer feedback, and polish the V1 before going loud.
• Train sales on the "why" before the "what." Sales teams need to understand who the product is for and why it matters more than memorizing every feature.
• Ship often and tell everyone. Frequent product updates (even small ones) signal momentum to prospects and keep customers confident they're on the right platform.
• Use launches to close the loop with customers. When you ship something a customer requested, let them know. It builds trust and shows you're listening.
• Don't sell the roadmap—sell what exists today. Customers buy startups for the vision, but committing to specific feature timelines boxes in your product team and doesn’t allow for smart pivots.
• Pair your PMs with PMMs as you scale. One-to-one relationships between product and marketing prevent features from getting "tossed over the fence" and keep launches coordinated.

Build the Messaging Before You Build the Product

We stole this from Amazon.

They have a famous practice called "working backwards" where product teams write the press release before they write a single line of code. If you can't articulate why a product matters and who it's for in a compelling way, you probably shouldn't build it. The press release forces clarity before you waste months of engineering time.

We're not quite that formal—we don't write full press releases—but the principle is the same. 

Alex thinks about launches from a commercial perspective from day one, even before the product is built. He's asking himself: 

• What's the category we're building for? 
• What's the marketing story? 
• How will the sales team position this? 
• How does this fit into our revenue enablement positioning?

For a big launch, Alex sends me the heads-up months in advance. For our LMS, it was back in December: "We're probably launching this end of March. Start thinking about it." At that point, the feature was maybe 30% built. 

That's when I start building the marketing message, which at its core is figuring out what sales will say about this product and why anyone will care.

To do this, I dig into Linear (our project management tool) and look at the design files. I watch Alex's Loom videos as he walks the designers through the flows. I click around in our staging environment even though half the buttons don't work yet. 

And then I start mapping out the messaging: 

• What problem does this solve? Who cares? 
• What makes this different from every other LMS on the market? 
• What objections will prospects raise, and how do we handle them?

Starting early forces clarity for both of us. If I can't figure out how to explain the product in a compelling way, that's a signal that maybe the product itself isn't clear enough. Sometimes Alex will adjust the roadmap based on what's emerging in the messaging. 

For the LMS launch, "certifications" became a much bigger deal in our messaging than we originally anticipated, so Alex moved that feature up on the roadmap to ensure it ships in V1.1 instead of later.

"Seeing the marketing message come together forces me to make sure the product is actually living up to expectations. Marketing sets the expectations of ‘what even is this thing’, and I want to make sure that whatever Eric is saying on the marketing website matches the reality of the product."

The downside of starting early is that things change constantly. A feature gets cut. A workflow gets redesigned. I'll write copy for the landing page and then Alex will tell me, "Actually, that's not going to be in V1 anymore." It's messy. But it works because we're working so tightly together. 

My advice for if you're in enablement or product marketing: get into the tools your product team is using. Don't wait for someone to throw a finished product over the fence. You'll learn more from seeing how the product comes together than you will from any kickoff deck—and you'll be able to train your sales team with actual conviction instead of regurgitating bullet points from a slide deck.

Ship Fast, Not Broken: Our Soft Launch Strategy

Once the product is actually built and tested, we do something a little unconventional: we launch it into production weeks before we tell anyone it exists.

When we're ready to ship something new, we don't coordinate a big synchronized launch where the product goes live the same day as the marketing announcement. 

Instead, we push the feature to production and let it sit there quietly as a V1 for two to three weeks.

We do this for a few reasons:

1. It gets us feedback and QA we wouldn't otherwise have. No matter how much testing happens in staging, there are always bugs and gaps you only find in production. Maybe something breaks on a specific screen size. Maybe there's a workflow you didn't anticipate. The soft launch period lets us catch those things before we blast the feature to 10,000 customers via email.

2. It gives the marketing process breathing room. I'm often still building the landing page or recording demo videos during this window. If we had to coordinate everything to launch on the exact same day, we'd either rush the marketing (and it would be mediocre) or delay the product (and engineering would be frustrated). The soft launch solves both problems.

3. It reflects our MVP philosophy about V1 products. Alex is adamant about this: Software should ship when it's functional, not when it's flawless. 

"No product should be perfect at the beginning. If you're building a perfect software product when you launch it, that's bad—you've taken too long to build it. Building software is a super iterative process. You got to build products that are not completely finished."

Sometimes we decide to make major changes to the product based on feedback during the soft launch. 

Sales will demo it to a few prospects and realize that a workflow is confusing. Or I'll be making a marketing video and hit a bug that makes the whole thing feel too janky. That feedback loop—between soft launch and marketing launch—makes a big difference for our customers.

Train Sales on the "Why" Before the "What"

Once the product is stable and we're getting close to the public launch, it's time to train the internal team. We do two types of training before we launch a new product. 

The first type is messaging-focused training. This is the "why" and the "who." This is about value selling—helping the sales team understand the problem we're solving and the buyer persona who has that problem.

The second type is product-led training. This is the "what" and the "how." What does the product actually do? How do the buttons work? What's the demo click path?

According to Alex, most sales teams need the marketing training more than the product training:

"The best sales teams are going to do value selling. They don't need to know the product as in-depth as your customer success team. Starting with the why and who it's for is almost more important than what the product actually does, which is funny and sort of unintuitive, but that's the reality."

Alex learned this at Lattice: start the training session by having marketing present the why and the who. Keep it simple—a few slides, maybe a one-pager to leave behind. Then the product manager (or in our case, also Alex) walks through the what and the how with a live demo.

For a big launch, we hold a live training session before the product goes public. This gives the team time to digest it and ask questions before customers start asking them about it. 

Then we create leave-behinds—at Dock, we use our own Playbooks feature for this, but a slide deck works too. And critically, we set up a demo environment, so sales have something to click around in and show to prospects.

One thing Alex does really well as our Product Manager: he doesn't just ship features and disappear. Every time we release something new—even small features—he posts in our company Slack. 

It's usually just a couple of sentences, a few screenshots, and a shoutout to the engineer who built it. It sounds small, but it keeps the whole team aligned on what we're shipping and why. And it's good for company culture—engineers get public recognition for their work, and everyone feels the momentum of a fast-moving product team.

Why Constant Launches are a Competitive Advantage

Now comes the actual marketing launch. A lot of companies batch their releases into quarterly updates or only announce the big tier-one launches.

But we announce every product launch publicly. Even the small stuff. We always do:

• A blog post to our Product Updates feed
• An email to prospects, free users, and customers
• A few LinkedIn posts, including a demo video
• Updates to our sales room template

This “rolling thunder” approach is a deliberate strategy with lots of benefits:

1. It signals momentum

Customers buy startup software because they believe in where it's going, not just what it does today. They don't want to bet on a company that ships twice a year. Velocity matters. 

When a prospect lands on our product updates page and sees that we've launched something new every week for the past six months, that tells them we're not stagnant. 

2. It gives us content

Product launches are some of our best-performing LinkedIn content. 

There's a popular sentiment in marketing that "no one cares about your product"—and that's true during the sales process. But as a marketing artifact? People are weirdly drawn to demo videos. People actually like seeing founders click around in their own product. 

Alex is very intentional about how he frames these demos. He's not clicking through every button. He talks more about why we built the feature and just quickly flashes the product. It's more like a mini-ad than a tutorial. The goal is to catch someone's eye and give them a reason to care, not to teach them how to use it.

3. It makes customers feel heard

If a customer requested a feature three months ago and we ship it, we close the loop with them. 

Maddy (our Head of Customer Success) is great about this. She'll message them directly: "Hey, remember when you asked for X? We just shipped it." That builds trust in a way that generic feature announcements never will.

There is a potential downside to this strategy: over-saturation. Customers can only absorb so much information. If we're emailing them every week with a new feature, at some point, they tune out. But honestly, we’d rather risk over-saturation than under-saturation. Momentum is a competitive advantage.

We try to manage this by limiting all marketing emails to once a week maximum, and we batch smaller features into "little things" roundup posts. 

A quick note on measurement: it's surprisingly hard to track the success of a launch. You can look at initial signups on launch day or launch week. You can track product usage and see if adoption spikes right away. But many launches have delayed impact—customers are busy, they're not paying attention to every email you send, and sometimes it takes weeks or months for them to discover a new feature and start using it.

And the brand/momentum benefit of building in public is almost impossible to quantify, but we see it show up indirectly in pipeline and customer trust.

What Role Should Sales Play in a Launch?

At Dock, sales plays three critical roles during a launch: they feed product feedback to the team, they're the first real-world testers during the soft launch period, and they close the loop with customers who requested features.

First, sales should be actively feeding product feedback back to the team before anything gets built. We run competitor intelligence meetings where sales tells us, "We're losing deals to this competitor because of these three features." Product goes and builds them. 

Then we want to see it in the numbers—our close rates should go up against that competitor. That's another way to measure launch success, especially when features are built with something really specific in mind.

During the soft launch window, sales acts as real-world testers. They'll demo new features to prospects and surface issues we didn't catch in QA. They'll realize a workflow is confusing or that we're missing a piece that would close deals. That feedback loop has changed products before the marketing launch more than once.

After we launch, sales helps close the loop with customers. If a customer requested a feature three months ago and we ship it, our team reaches out directly. "Hey, remember when you asked for X? We just shipped it." That's a sales and CS collaboration, and it builds trust in a way that generic announcements never will.

Then there’s the future-facing question: should sales talk about the product roadmap with prospects?

Alex used to think public roadmaps were great—transparency, customer trust, all that. Now he's completely against them. Roadmaps box you in. They reduce your flexibility to build the right thing. And they create broken promises when timelines inevitably slip.

The philosophy at Dock is to sell what exists today, not what's coming tomorrow.

Customers and prospects want to know where you're going, but they want it at a high level. "We're building toward a revenue enablement platform, and LMS is part of that vision" is fine. "We're launching LMS on March 13th with these seven features" is not. The first gives you room to maneuver. The second locks you in.

There are exceptions. If a prospect says they can't buy you without a feature you're building, and that feature is solidly on the roadmap (two months out, not a year), it's fine to mention it. But Alex's default position is: if they need it right now, they shouldn't buy Dock. They should buy what exists today and trust that we'll keep making it better. 

What Breaks at Scale (And How to Fix It)

Much of what I've described so far works because Dock is small. Alex is the CEO, the product manager, and deeply embedded in marketing. I'm the only marketer. Our sales team is four people. We can move fast and stay coordinated without a ton of process.

But Alex has seen what happens when this breaks at scale. At Lattice, there were multiple product managers, multiple product marketers, different sales segments, and way more people involved in every launch. The things that work for us now would completely fall apart in that environment.

1. Communication between product and marketing

When you have 10 PMs and five PMMs, stuff inevitably gets thrown over the fence. A PM ships a feature and forgets to tell anyone. Or a PMM finds out about a launch two days before it goes live and has no time to prepare.

The fix is to pair PMs with PMMs. Ideally one-to-one, but that depends on team size. The pairing can be by product line (one PM and one PMM own the "content management" product) or by customer segment (one PM and one PMM support the sales enablement buyer). 

Either way, those two people need to be in lockstep. They should meet regularly, they should share a launch calendar, and they should co-own the success of every launch.

If you don't have enough people to pair one-to-one, the fallback is a recurring meeting where product presents the roadmap to marketing and customer success. It's not as tight, but at least everyone knows what's coming. 

2. Sales enablement bandwidth

At a bigger company, you can't ship features constantly and expect the sales team to keep up. They're already overwhelmed. They have quota to hit. They're not paying attention to every Slack message about a new button.

This is where sales enablement (as a function) becomes critical. Enablement owns the calendar of what sales needs to learn and when. They decide what's actually important enough to train on versus what can just go in a changelog. And they work with product and PMM to create the training materials and run the sessions.

For really big launches—the tier-one products that change your positioning or open up a new market—you might even need a certification process. Sales reps have to go through the training, pass a test, or do a mock pitch before they're allowed to talk about the product with customers. That sounds intense, but at scale, it's the only way to ensure quality and consistency.

3. Launch cadence

At Dock, we ship constantly and announce constantly. At a bigger company, you can't do that. You'll exhaust your internal teams and your customers. So you need to tier your launches more carefully. 

• Tier one launches get the full treatment—live training, big marketing push, maybe even a user conference moment. 
• Tier two launches get a lighter touch—async training, a blog post, maybe some LinkedIn ads.
• Tier three launches might just go in a changelog and a monthly roundup email.

User conferences, by the way, become massive forcing functions for launches at scale. Salesforce's Dreamforce is the obvious example, but Lattice did this with their Resources for Humans conference. The entire product and marketing calendar gets oriented around that one event. You want to launch your biggest, most impressive stuff on stage in front of thousands of customers. 

It's partly to make the conference worth attending, but it's also a way to focus the internal team. If the CEO is going on stage and needs something to announce, that creates real pressure to get the product done. It's motivating in a way that abstract deadlines aren't.

We're still learning. Every launch teaches us something new. But the core principles hold up: 

1. Start with messaging
2. Ship before you market
3. Train on the why before the what
4. Build in public
5. Protect your flexibility to build the right thing

Watch the full episode

Watch Alex and Eric's full conversation on Grow & Tell, Dock's podcast for revenue leaders.