How we scaled product marketing for success

Hi there! I’m Karen Sheffer, the Director of Product Marketing at HiBob. Today I'll be sharing how product marketing helps accelerate growth in organizations. I'll also equip you with some real-life strategies that you can use to scale product marketing for internal and external success, based on actual events that happened at HiBob.

Moving HiBob from the BCE of PMM to the CE of PMM

I joined HiBob four years ago, when we were a product- and tech-heavy organization of only 60 people. From a product marketing perspective, it felt prehistoric!

Product managers planned features, developers built features, and product managers even wrote help articles in Hebrew-ish (a fun mash-up of Hebrew and English). It was not pretty. How could customers learn about new features if product managers were the only ones working on them? My challenge was to bring HiBob into the modern age of product marketing.

So, let's talk about how I tackled bringing product marketing into this product- and tech-heavy organization. I felt like that white bear on the right – all of our products and features were going into this deep freezer, and you couldn't get at them even if you wanted to. I had to become that frazzled brown bear, frantically getting them out.

So how did we make this happen? How did we get the features flying off the proverbial shelves? Let me show you.

Step one: Establishing processes

As anyone who knows me will tell you, I love a process. The first thing I tackled was the priority matrix. You may already be familiar with the standard product marketing priority matrix. It's pretty common, and hopefully, you use some version of it. However, I felt that the standard matrix wasn't a perfect fit for our objectives at HiBob. So, I took it upon myself to create a version that suits us better.

Next on my agenda was integrating product marketing fields into our roadmap planning board. This tweak provided a simple and easy-to-navigate platform for us to manage critical pieces of information for every feature we were developing.

Then, of course, who doesn’t love a launch template? I built one out with the goal of streamlining the planning and execution process so we wouldn’t have to start from scratch for every product launch.

Lastly, I took the liberty of clearly defining roles and responsibilities. Until this point, product managers were operating independently, calling all the shots, and pushing features for the developers to execute. It was time for me to get all up in their business. To avoid any confusion, I made it crystal clear what my job entailed and what their duties were. This step was crucial in ensuring that everyone was on the same page.

Step two: Education

Having laid the groundwork, I then focused on making the priority matrix more understandable. I added simple language descriptions for each quadrant, explaining what they mean.

To make the concepts more relatable, I used recent feature releases as tangible examples. This way, the team could see how I would map these items onto the matrix and how it would influence our decisions and launch activities.

Another essential part of this process was ensuring everyone knows what's in it for them. Otherwise, why should they join us on this journey? Why put in the extra effort or disrupt their existing work cycles? I had to show them the added value of this change and how it would help them achieve their ultimate goal – adoption.

Finally, I had to bring all this together and show our product teams the bigger picture. I presented what the new processes would look like from start to finish, so everyone understood how these changes would contribute to the ultimate value they were looking for.

Step three: Go!

At first, everything seemed to go as planned. The product managers, developers, and I would go through the features they were working on, step by step. We had fun along the way as well. Our developers have a Slack channel where they share and celebrate every feature release. I got to join this exciting ritual and share in their joy.

However, the surprises soon started rolling in. There were surprise releases, which either the PMs weren't aware of or hadn't approved. At other times, a release went live without the PM consulting me. These scenarios underscored the need for stricter control measures.

A separate issue that popped up was our lack of support coverage over weekends. And, of course, every new release carries the potential risk of support tickets. Unfortunately, we hadn't thought about this, so we had some hard lessons to learn.

Step four: Optimization

The silver lining of all these hiccups was that they allowed us to optimize our processes.

We understood the need for a formal cadence between the PMs and myself to review every single line item of the product roadmap. This way, nothing falls through the cracks. At first, a monthly meeting was sufficient, but as the organization and the number of PMMs grew, we shifted to bi-weekly and then weekly meetings.

Another change was to enforce a strict rule of no releases on or right before weekends. We also mandated that PMs should have complete ownership of the product, and without their green light, no feature could be launched.

The tools that made a difference

Tools are our friends, and along this journey, several tools helped us work more effectively. Let’s take a look at some of the most useful tools we leveraged:

Intercom became my go-to tool for managing the knowledge base, customer emails, and sending out a monthly roundup newsletter.
Pendo was our tool for in-app messaging and enablement. Before Pendo, we had only been able to do enablement via live sessions on Zoom.
Guru came in handy for content management.
Mac’s built-in tools allowed us to build tutorial videos.
Google Slides is my go-to for competitive battlecards.
Airtable became our preferred tool for product planning.

Interestingly, while we had all these tools, we didn't have a dedicated project management platform at this time.

HiBob in PMM C.E.

We did quite well. We made significant strides in bringing HiBob into the common era of product marketing. We were experiencing lightning-speed product-led growth, our users were engaged, our customer churn was minimal, and we fostered a vibrant community of users.

We also started a monthly roundup and heard in CABs that our customers were eagerly awaiting the newest edition each month. Our open rate increased from 40% to 55%. This showed that our customers were highly engaged and always keen to know about the latest developments in the product.

After living and breathing this process for a full calendar year, and being a one-woman show, I successfully put Bob on the map for our customers. Plus, our once non-existent internal enablement became something the company relied on and looked forward to. In one year alone, we rolled out 142 feature releases - a testament to the power of our continuous release strategy.

Scaling goes viral

The tremendous success brought about scaling, and it was everywhere. Scaling is a phase that just happens - it doesn't check if you're ready. In our case, it happened internally as our company expanded from 60 employees to almost 800 in just four years.

Our customers were also growing in size, and we were onboarding more customers who were now larger due to our upmarket business strategy. Growth was all around us, and as we grew, so did the needs, appetites, and requirements. Everybody wanted more from product marketing.

Not only had we grown in size, but we had also grown geographically. We established offices in various cities like London, Tel Aviv, New York, Sydney, Amsterdam, and more. This meant we had to consider different time zones and holiday calendars.

The rapid growth required us to move at a lightning-fast pace. As is often the case in fast-growing companies, everybody wanted everything yesterday. The demand was high, and the need to deliver was urgent.

Scaling the team

To do more, we needed more people. By the time we were shipping 142 features a year, I was no longer a one-woman show. I had an additional PMM and someone managing our knowledge base. Hiring a PMM was challenging, probably due to the scarcity of experienced product marketers in Israel three years ago. Plus, given my workload, I couldn't afford to train someone without prior experience.

I had to take a step back and strategize on building my team, a hot topic of conversation in our industry. You can structure teams by market segments, specialties, product lines, and more. There’s no one-size-fits-all answer; the best structure for your product marketing team depends on the company.

To meet our business’s needs and mitigate the challenges of hiring PMMs in Israel, we decided to structure our growing team by specialty. Today, we have three distinct groups – product marketing, market intelligence, and product education – each with leaders who excel in their areas. This level of expertise is hard to achieve outside of the specialty structure.

Streamlining processes

Back to my favorite topic – processes! With the team in place, we turned our attention to processes. To maintain efficiency as we scaled the organization, it was time we finally started using a project management tool, so we introduced Asana.

The next hurdle we tackled was the lack of streamlined cross-functional processes, especially within product marketing. Without proper planning and automation, you risk drowning in tasks and dropping balls. To prevent this, we designed a new product roadmap, outlining how it feeds into development, and then into product marketing.

From there, we took a close look at our product launches. We focused on how each launch feeds into our content creation and design teams, among others, establishing processes that ensured smooth coordination and delivery.

Scaling enablement

Enablement training also presented its own unique challenge with our expanding global team. Coordinating meetings between the West Coast of the U.S., Sydney, Australia, and Tel Aviv, Israel can be a logistical nightmare. So, we set about creating a unified process for enablement training, aligning it with our impact levels.

The 'train the trainer' strategy proved invaluable. As our organization grew, we developed new roles like sales engineers and subject matter experts in customer success. These individuals, with their technical expertise, were perfectly positioned to help with more complex training.

Lastly, we addressed the need for improved tools for content management. We had been using Guru, but it wasn't keeping up with our growth, so we transitioned to Highspot for content sharing.

Not only did Highspot meet our content-sharing needs, but it also provided learning management system (LMS) functionality. This allowed us to develop our training and enablement via courses, and move toward video-based content rather than live sessions. It also gave us the capability to check knowledge retention, ensuring that our team not only consumed the training materials but also fully understood them.

Highspot also gives us enhanced external communication capabilities. Our account executives can attach customer-facing content created by product marketing to emails. Plus, we get to monitor what’s being consumed, how, and whether it’s being shared internally or externally.

To step up our competitive enablement, we started making greater use of Klue. It enables you to send out weekly industry intel digests, create in-depth battlecards, and provides those all-important analytics.

As you scale, those data and analytics become vital. No matter the size of your resources, they will never seem enough. Analytic insights help you understand where you should allocate your resources effectively.

Another crucial aspect of scaling is ensuring systems integration. As we introduced new tools, we realized that effective integration could mean the difference between adoption and neglect. For instance, integrating Klue into Salesforce, a platform our sales team uses daily, significantly increased engagement with this tool.

Transitioning to a recurring launch rhythm

As we were enhancing our internal processes, we also realized that our customers' needs were evolving. We were constantly launching new updates and telling our customers about them. Meanwhile, they made it clear that while they wanted a heads-up about changes, they wanted less noise. We had to strike a balance between promoting feature adoption and not overwhelming customers.

It became clear that we could no longer continue with constant updates. We needed to transition to a recurring launch rhythm.

Step one: Establishing internal requirements

We'd heard our customers loud and clear; now we needed to pinpoint our own needs. What did we want to maintain?

One priority was being able to turn around new features in the shortest possible time frame. Our tech teams also wanted to keep that dynamic culture of quick pivots, ensuring we didn't inadvertently create any self-imposed roadblocks that might slow down our bug fixes. Plus, we needed to give teams enough time to digest new enablement materials.

Step two: Managing decision-makers’ fears

Surprisingly, a major part of the process was managing the decision-makers' fear. They were scared of closing the door on our continuous release strategy and wanted to leave it open just a crack.

Step three: Defining the new launch cycle

The conversations and negotiations were tough, but we finally defined what our recurring launch cycle would look like, what it would involve, and when exceptions would be allowed. We kept the door ajar for bug fixes and small, customer-centric features outside of the launch cycle. However, product marketing made it clear that these exceptions would receive less support.

Step four: Designing our release cycle

Then came the task of fitting together the puzzle pieces of internal and customer requirements. Our dev team had always operated on a 30-day sprint. After some deliberation, we decided a one-month, four-week launch cycle would harmonize with their sprint and satisfy all other requirements. It might sound straightforward, but from the product marketing perspective, it's a monumental task.

Step five: Education and rollout

The final phase was a tough hill to climb. It involved challenging conversations, particularly with our devs. They weren't thrilled about being pushed into this new framework. In the end, it came down to a value sell. We drove home how this change would attract more adoption and attention to their hard work.

How did it go?

So, how did it all pan out? Well, in the early days, there were definitely some rule-breakers. Remember that negotiation about keeping the door ajar for exceptions? Our team likes to call those exceptions "fire-at-wills," and there were a bunch of them.

Naturally, this led to some heated disagreements between product managers, PMMs, and dev team leads. At times, I felt like the Grim Reaper standing at the gates, saying, "Your feature may not enter."

It was tough. Especially when we reached the go/no-go decision point. If someone said they weren't ready, or there was a bug that required a day or even just a few more hours to fix, it meant they'd have to wait another month to release their feature. That was a hard pill for them to swallow.

But looking at the situation today, we don't have many of those issues anymore. The team adapted. Sure, it took some time for them to adjust to this new normal. But in the end, our customers are happier, we're better off, and it works.

This article is based on Karen’s brilliant talk at the Product Marketing Summit in Tel Aviv. You can watch the recording in its full unedited glory here, and head to your membership dashboard to watch even more fabulous talks OnDemand.

How we scaled product marketing for internal and external success