Introhive Scores Fast 50 Hat Trick | The only Atlantic company to make Deloitte's list three times. | Learn More

Skip to main content
Blog Marketing

Building a scrappy beta program—Part 3 of PMM with Julie Taylor

This is part 3 of a multi-part series all about Product Marketing. Introhive’s Director of Product Marketing, Julie Taylor, will guide you through the ins and outs of creating a product marketing group from scratch. You might want to begin with the introduction to the series if you haven’t already.

In this series, Julie draws upon her own experience and extensive research, letting you in on all (well, almost all) of her trade secrets about essential PMM programs, and passing along all the lessons she’s learned along the way to building a successful team that made the finalists in 2021’s Product Marketing Awards.

This time, Julie talks about how to start your Product Marketing department with a beta program to test ideas and get feedback. Start smart, finish strong.

If you watched my first video of this series, you already know how my first day started. That morning, after setting up my computer, I was promptly introduced to the first product I would witness in development at Introhive.

To be totally honest, I hadn’t even seen our core products that were already in market. In that demo, I realized very quickly what my first duties were going to be, and wow they were really big for day 1 in product marketing, at a new company.

Step one: brainstorm

First I needed build out and stand up a beta program where I could generate feedback from early access customers, and then i needed to figure out how to launch this bad boy into the market. Lucky for me, I legitimately adore being thrown into a fire, otherwise I likely would have thrown my fancy blazer back on and made a swift exit. 

Instead, I whipped out my brand new notebook, noticed that no one at an up and coming SAAS company use paper-based notebooks, put it back into my laptop bag, and proceeded to brainstorm what an MVP super-scrappy beta program could look like.

How do you start a beta program? They can get really formal. They can be very complex. They can be qualitative, they can be qualitative, they can be both, they can be …neither?

My gameplan was to identify customers that would be a good fit for this program, and then lure them with free product if they agreed to touchbase every so often. This touchbase included biweekly calls, emails exchanged, surveys, and a sprinkle of homework. Ideally after the beta program, product mgmt would know what areas needed work, and I would have market problems, lay of the competitive land, key messages& positioning, use cases, personas, and would have exactly what I needed to develop a rock-solid GTM from there. 

A step-by-step recipe for beta success

Because it was my first beta program, I learned a whack of lessons. I’ll attempt to do this in chronological order:

  • Defining our objectives seemed like the most obvious place to start. This is much easier to do if you work with the product manager—they’re going to get a ton out of this program as well
  • My PMM-based goals came down to these buckets:
    • Is this product ready for release, or does it need more work? If so, what work?
    • Who are the users of this product?
    • What are their current workarounds? Are there alternatives?
    • What are the pain points that it’s aiming to solve?
    • What is the business value?
    • Are there any tangible results or customer stories I could leverage in launch?
  • Once you’re set on goals, you need to then define the timeline of the program with start and end dates and schedule of key milestones. Also think about the process for how you would go about making an extension for specific customers if circumstances warrant it.
  • Know what documentation, training, and assets you need to be successful—make sure you understand how will it be installed or enabled, how customers will be trained, and how they’ll be supported from a technical standpoint
  • Something fairly important is identify who is an ideal fit with potential selection criteria. At that point, i didn’t know our customers well, so i relied on CS and sales to help me recruit. Here are sone considerations I provided my team:
    • Make sure they’re compatible
    • Constructive feedback
    • Willing and able to carve out time to spend in the product
    • Willing to spend time with me every 2 weeks on top of that
      • Yes it’s time we’re asking them to devote, but at the end of the day, they’re helping mold raw innovation and it’s an exciting endeavour that many customers will be happy to help out with if they have the capacity; ensure that is part of your messaging
  • Once you’ve worked with sales and customer success on identifying the candidates, and they’ve agreed to participate, make sure you get up to speed with the account in advance of meeting the customer (especially if it’s your first time, you want to instil confidence in these conversations)
  • Set expectations up front: 
    • Customers should know the framework of the program, what’s needed from them, what types of things they’ll be helping solve. In our case, i prepared an info packet to help lay this out. 
    • Another tip, encourage customers to raise product bugs directly with support – keep control of the conversation, otherwise it may lead back to potential cases that are actively open instead of new product validation
  • Build out your interview guides:
    • Do a pre-beta questionnaire—this give you a benchmark to compare against at the end of the program 
    • Incorporate open ended questions that are vague like “what didn’t i ask that i should have”
    • Ask them to complete a couple workflows—base them on most common use cases you expect—if they can share their screen or record, even better (product design will love you)
    • Active listening is critical—find the problems, not necessarily their solutions. Always ask “why” one more time even if it feels awkward
    • Be prepared to be asked about the roadmap and never overpromise—it only leads to ruining your credibility you’ve worked so hard to build. Your product will hopefully solve a pile of problems, but it can’t solve them all. Remember that.
  • The information collected from these calls should be sliced and diced, and presented in multiple ways so that it can be efficiently utilized. We kept ours in google docs, but I’m sure there are much better places to house this information. Potential ways to categorize:
    • Call notes by customer
    • Feature requests
    • Notes by area of functionality
    • Customer status
    • High Level findings
  • Alwaysssss do a post-mortem to understand what worked, what did not to optimize future betas
  • And last but certainly not least—disseminate your findings.everyone across org will find this information valuable.  Sometimes I like to combine customer recording snippets into an mp4, it helps formulate your voice of customer and supplement that pitch in a sales cycle by tenfold

This particular product (called Cleanse) that I started with on my first day at Introhive is STILL one of my favourites. When you can get that close to customers that you can express & represent their needs, that’s every product marketers dream, and that’s the potential of a beta program—scrappy or not.

Is Product Marketing your jam?

We’re deep into the process of building a Product Marketing program now, but there’s a lot more. Next up we have a biggie, all about upsell campaigns, account growth, and accelerating LTV, and while you’re waiting for the rest of the series you should also take a peek at more from Introhive’s Product Marketing group.

Guides

Sharpen Your Law Firm’s Competitive Edge