Matt Hodges

We’ve developed a few of our own frameworks over the years based on jobs-to-be-done. It’s an approach that runs counterintuitive to classic, persona-based marketing, and does so purposefully. Focusing on customer attributes really means focusing on what you want to sell, rather than what your customers actually need. Those customers come from a variety of backgrounds, industries, and verticals, but their one commonality is their motivation, the Job-to-be-Done.

I had to fundamentally change my approach when I joined Intercom. For me, the easiest way to grok the Jobs-to-be-Done methodology was by watching Clay Christensen’s famous milkshake video and understanding what “job” people buy milkshakes for. You can read more about Jobs-to-be-Done on the Inside Intercom blog here: Focus on the Job, Not the Customer: https://blog.intercom.com/when-personas-fail-you/

And, here’s a recording of a talk and podcast I’ve given in the past about how we apply JTBD to our go-to-market strategy.

How to market the Job-to-be-Done: https://blog.intercom.com/marketing-the-job-to-be-done

How Jobs-to-be-Done Informs Intercom Marketing: https://blog.intercom.com/podcast-intercoms-go-to-market-strategy/

As we continue to grow, our products mature, and we learn more about the problems we’re trying to solve and for whom, we’re constantly adapting our frameworks.  As an example, we’ve recently created an internal document called the “Solution Guide” for each of the solutions we take to market. The guide answers the following questions:

Foundations

• What problem are people looking to find a solution for?
• What will a solution to this problem improve for them?
• Who is looking for it?
• What are the keywords they are using to search for it?

Solution Positioning & Messaging

• What do we call the solution we provide for this problem?
• Why would someone be interested in Intercom’s solution?
•  Which Intercom products are required to solve this problem?
   
• How does Intercom solve this problem?
• Which must-have features for this problem does Intercom have?
• Why would someone want to use Intercom to solve this problem?
• Who is successfully using Intercom to solve this problem?

In addition, as we think about how to best position ourselves against alternative solutions (products) to the problems we solve, we make use of the 4 Forces model. You can learn more about that and our approach to comparative marketing here: The right way to challenge your competitors - Inside Intercom: https://blog.intercom.com/comparative-marketing/

Of course, there are many other, more established frameworks available to you. One thing I have heard good things about is Pragmatic Marketing (https://www.pragmaticmarketing.com/).  My advice would find a framework that feels good and adapt it to your business because everyone is different. :)

For guidance on how to build messaging, see my answer to, What are good messaging framework resources that you use?. In terms of how to validate it, I’d recommend a combination of the following tactics:

• Talk to your customers: Invest time talking to and learning from your prospective and existing customers. Specifically, listen to how they describe the problems they have, the pain points they experience, and what a better world would look like for them (in their minds).
• Partner with your sales team: Your sales team are on the frontlines and spend a lot of time talking to prospective and existing customers understanding their needs. Work with them to test your messaging on calls and in conversations. It’s amazing and eye-opening to simply listen in on a sales call, or watch a live chat conversation unfold, and hear/see what resonates and what doesn’t. It's so, so valuable.
• Conduct user tests: We're fortunate enough to have a dedicated Research team that we can partner with to test our messaging and positioning, particularly for new product and feature launches, to validate our own assumptions and ensure the story we are telling resonates and makes sense.
• Run A/B tests: To the extent you can (you need volume), run A/B tests on your primary marketing assets (e.g. ads, landing pages) to see which messages drive the best conversion and LTV throughout the funnel.

I can’t think of any one example I have received recently, but here’s my advice on what I think makes a good feature launch email:

• It’s thoughtfully targeted and relevant: A poorly targeted email is about as effective as a love letter addressed “To whom it may concern” (credit: Des Traynor). It frustrates me when I get emails about a new Android app, or update to an Android app, when a business should know I use their product exclusively on iOS. Make sure your audience can, and would be compelled to, take action on the news you are sharing.
• It’s clear, concise, and to the point: A great email should do three things to pique just enough interest and motivate action: tell you what’s new, show you what’s new, and tell you why you would want to use it (not how it works)

There are some great tips in this post, How to send good email – opens, clicks, conversions (https://blog.intercom.com/email-101-opens-clicks-conversions) and our newly published book, Intercom on Customer Engagement (https://www.intercom.com/books/customer-engagement).

Additionally, if you're not sure what you should announce and how, check out my post on the Inside Intercom blog, Prioritizing product announcements in a SaaS world (https://blog.intercom.com/prioritizing-product-announcements-saas-world/).

Great question–tough to answer without getting too specific about Intercom and what works for us based on our own situation and approach in general. But, here goes. :)

For us, a product is a container for a set of mutually exclusive features that enable specific workflows to be completed. For example, our Engage product has a set of core features (available on Engage Lite) that make it possible to send targeted messages to leads and customers. Some of these features are audience targeting, auto messages (email, in-app, and push), and smart campaigns to name a few. There is an optional additional set of features available for on Engage Standard that enable more sophisticated workflow to be completed. For example, A/B testing allows you to optimize the targeted messages you are sending to leads and customers.

Our products can be applied on their own, or in combination with other products, to solve different problems for different teams–these are what we call solutions. For example,  Engage can be used on its own by marketing teams to onboard, activate, and upsell more customers. When combined with our Respond product, sales teams can use the same features to capture, qualify and convert more leads.

FWIW, internally we're not in love with the word "Solutions" because of some of the connotations it carries with it. Additionally, like 'Products', it's also noun which can cause confusion, since you don't buy "Solutions" from Intercom, you buy "Products" which can solve different problems based on how you apply them. We're still working through this. It's not easy and I've not come across anyone who does it particularly well.

PM and PMMs are likely to have different goals when it comes to feedback from users with early access, but I think that both should at the very least seek to understand, "to what degree have we solved the problem for customers that we set out to solve with this feature/product/release?". If you practice jobs-be-done, that question might be better phrased as "is the user able to hire our product for their job-to-be-done? Why or why not".

As for PMM-specific expectations, I would base these on the goal of your alpha/beta, which you should align with PM on upfront. For example:

- Validate Problem-Solution fit

- Uncover and fix issues ahead of GA

- Source reference customers for a marketable moment 

- Improve the UX before GA

- Inform positioning and messaging

- Inform pricing and packaging

Lastly, I've never given or been involved in a project where an incentive other than, "get early/exclusive access", was offered. If you're building the right things for your customers, you should have no issue getting users wanting to participate in a beta. In theory. 😅

I'm out of time, but real quick, Patagonia and Apple are favorites of mine. They both have brands that stand for something, and they continually demonstrate their commitment to their vision in their actions. On top of that, they both have high-quality products.

I  believe that product and marketing are two sides of the same coin–you can't be a successful, sustainable business without one or the other.

Research

• Competitor analysis to identify gaps to fill and opportunities to strengthen your unique value proposition 
• Customer research to understand needs and willingness to pay
• Market and analyst research to inform how to strengthen your position in your category
• Win/loss analysis with sales to identify common blockers and hurdle

With regard to the tangible output, see my answer to, "How do you influence the product roadmap if the roadmap has already been laid out by product?".

This all depends on both your pricing and company strategy, which together determine to what degree revenue opportunity should be weighted when making roadmap decisions. Are you currently focused on optimizing for usage, growth, or revenue? Only you can answer that.

In my experience, instead of focusing specifically on revenue, I prefer to prioritize based on "impact" of which revenue is just one measurable component. I could go into more depth on this, but the fine folks over at Intercom have a fantastic post on their blog on this exact topic–Ship outcomes, not just features, with the Product Impact Framework.

At the stage before anything is handed over to eng for design. At Atlassian, we refer to this as the "Explore" phase–"Wonder" and "Make" come before and after, respectively. 

When you do this, be clear on the role PMM is playing and the type of feedback the design wants and needs to move forward. In my opinion, that feedback should not be focused on visual design.

Product roadmaps are, or at least they should be, always subject to change. At least that is what a PM will tell you when you want to share the roadmap with a customer. 🤣 So, use that to your advantage.

tl;dr

Make a case for change and back that case with hard evidence

Longer answer

I would suggest you start with a repeatable process for ensuring PMM has the opportunity to bring its value in the form of rich customer, market, and sales insights to the table when the roadmap is being updated. In the earlier days of Intercom that was quarterly. Each PMM would produce a "GTM Recommendations Report" for their respective product or product area, which summarized the top 3-5 "problems to be solved" (intentionally not "features to build"). Each recommendation was backed with qualitative and quantitative evidence as to why it should be considered for the roadmap. This evidence included win/loss data from sales, feedback from customer support, and of course a PMMs view of the market opportunity based on their knowledge of the competitive landscape. It was PMs' responsibility to take those inputs and provide a rationale on why something made or did not make the cut. The process has since evolved, but it was a successful starting point for improving how GTM and R&D worked together.

Lastly, a former team member and still good friend of mine, Jasmine Jaume, has a great post on this topic here. And, if you are looking to get that elusive "seat at the product table", check out my tips here.