In the tech/software world, I’m often asked how best to scale the Product Marketing function and how to make it a highly performing function in a growing organization. Really great product marketers are masters of understanding the problems their products solve, positioning those products, identifying ideal buyers and personas, and knowing the overall market. But that’s only where their work begins...
Wednesday, November 20, 2019
Improving Your Product Marketing Alignment
Product Marketing is a highly-networked function with multiple internal touchpoints that need to be actively developed and curated
Friday, November 8, 2019
Measuring Marketing is Science, Not Art.
“If you can't describe what you are doing as a process, you don't know what you're doing.”
~ W. Edwards Deming
When in business school, I had the honor of meeting W Edwards Deming while taking a class on operations management. Deming literally wrote the book on quality and process control, and is known for his 14 Points of Total Quality Management. But only when I entered the realm of product marketing did I realize that many of Deming’s principles can directly apply to marketing process quality as well.
As a product marketer, I’m always asked about how to set objectives, goals and actions for marketing - for individuals, for teams, and for organizations. My approach is to first ask about what the desired *outcomes* are - the OKR approach (Objectives and Key Results) and then analyze and break-down the stages of the marketing loop.
I use a “loop” concept (and not funnel) because when marketing is done properly, it’s not a unidirectional process that ends with a sale. Rather it should feed on itself with customer loyalty and advocacy, ultimately helping you generate even more awareness. When marketers refer to the funnel, it only corresponds to the stages of Discovery through Purchase… so if you don’t include the post-purchase stages, you’ll be blind to monitoring customer experience/use, loyalty and advocacy. Hence the value of the loop concept.
Step #1: Break down your stages / define your marketing processes
I like to use this 8-stage loop that’s specific to enterprise software marketing and purchases - but you can adapt it to your unique product/market circumstances. In whatever manner you use it, It’s critical that your team crisply define each stage, and even the customer personas and desired interactions at each point in the loop. Work with your team to drive agreement on stages that seem logical to your organization. For example:
- Discover: How, when and where potential buyers initially discover your company and products; it’s your first opportunity to expose your brand.
- Learn: Where and how potential buyers learn more in-depth details of your products and fit-for-use
- Compare: The first time potential customers begin to consider (and sometimes demo or trial) your offering, pricing etc. in the context of your competition or other close alternatives
- Choose: Where your decision-maker and influencers ultimately downselect to you over the competition. This could include “bake-off” comparisons, etc.
- Purchase: When, where and how your customer (and often, their purchasing agent) ultimately transacts (with you or with a channel partner of yours). This might be a one-time purchase, a subscription, site-licensing, etc.
- Usage: Post sale, where your customer (often many internal users) actually engage with your product - and hopefully derive the intended value you provide.
- Loyalty: The affinity that your customers develop internal with/for the product, your service, etc.
- Advocacy: Where, if your customers are delighted, they’ll become advocates of yours, helping drive continued discovery by new potential customers.
Step #2: Define metrics…. And team accountabilities
Once you’ve defined a set of marketing stages that aligns to your unique org, the most critical part of the process is to define “exit gates” (essentially outcome or OKR metrics) from each stage as it flows into the next. Getting these gates and metrics right is critical because they provide you with the process control and trends of each *outcome*. In this manner you can adjust each stage’s marketing *actions* while keeping how you measure their outcomes consistent.
The example I give here is just that… your set of metrics, naming, etc. will be different.
But one thing is important to internalize: The metrics measure the effectiveness / outcome of each stage, and *not* the activities in each stage. For example, in the “Learn” stage, we don’t want to measure the number of events attended, blogs posted or papers written. Instead, you want to measure the number of attendees you achieve at events, blog views, and paper views/downloads. (Think content consumption not content production)
If resources permit, I also recommend that you organize the marketing organization in a way that a single person (or team) is directly accountable for the outcome metrics at each stage. These individuals need to be singularly focused on the effectiveness - and outcomes - of each stage, working with the other teams to continuously improve the activities (and thus, the outcomes) at each gate.
During your regular marketing and business reviews, effectiveness trends of each stage should be evaluated, and actions adjusted appropriately. The key to process control is to precisely and consistently measure the outcomes of each stage - which I’ll explain next.
Step #3: Metric Definition
Finally, the most overlooked aspect of the process is defining exactly *how* your team plans to consistently measure each outcome. It’s not as simple - or as obvious - as it might seem. For example, how will you count content views? Is it just pageviews + downloads? Which pages and which content? Are “views” limited to your website or will you include YouTube and 3rd-party syndicated content? And if syndicated content, then from which partners? (And, how to *they* measure “views”?) Getting these details right and repeatable is important because these are the specific outcomes you’ll be trying to impact by continuously improving your marketing activities.
Your Mileage May Vary
This is just an example. It will probably vary wildly based on they type of product you sell - if it’s a service, or B2B, or B2C etc, the stages and metrics will vary considerably. My advice? Dissect your buyer’s journey into as many distinct phases as you can, and map your marketing organization’s activities/outcome onto it. That way, you can apply as much process control (and continuous improvement) as possible.
Other thoughts/ideas? I’ve love to hear them!
Thursday, September 19, 2019
The Argument for Public Product Roadmaps
“Can you please share your roadmap?”
“What are your plans to engineer feature xxx?"
“Great product, but does your vision match ours?”
I've received these questions all the time, from customers, partners, and analysts.
When leading Product Marketing at an open source software vendor, I felt it antithetical to be open and transparent about code, financials and priorities - but not about our actual product roadmaps. So we decided to open-up our product and solution roadmaps for each product. And on reflection, if you're selling enterprise software, it's probably a good idea for you to consider this approach too (whether or not your product is open source).
Why do this? Are you crazy?
There are a number of reasons to consider taking this bold step - a step that many high-tech companies shun as competitively risky - and thus guard their roadmaps with absurd paranoia.
Are you nuts? The competition will clobber us!
In reality, your competition is probably dealing with their own internal politics, debates and direction - and may not have time to seriously consider yours. And if they do take your roadmap into account, that generally indicates that they'll be a follower, not a leader.
OK, I get it. But what will Legal say?
True, your counsel will generally play the safe/conservative card. Their concern generally takes one of two angles: (a) Corporate liability if you somehow don't fulfill on your promises to customers and/or to the market, and (b) risk to near-term revenue by possibly stalling sales... if customers sit back and wait for you to actually deliver on the promised features.
To these, I respond with a bit of marketing pragmatism: First, you should always add some form of legal disclaimer to your roadmaps. Roadmaps are your best, honest intentions - but they're not guarantees... so say so. And, roadmaps have to do with *direction*, not necessarily with granular specifics - so it's OK to be vague and avoid details that could changes as development runs its course.
And regarding stalling purchases/revenue, consider this: If a customer is going to delay a purchase to see whether you deliver on a roadmap component, you probably run a greater risk of that customer going to a competitor in the interim. So I say, try to win them over *now* with your direction, and maintain their allegiance as you build on your roadmap.
Thoughts? In the theme of transparency, I'd love to hear yours !
Other Resources:
“What are your plans to engineer feature xxx?"
“Great product, but does your vision match ours?”
I've received these questions all the time, from customers, partners, and analysts.
When leading Product Marketing at an open source software vendor, I felt it antithetical to be open and transparent about code, financials and priorities - but not about our actual product roadmaps. So we decided to open-up our product and solution roadmaps for each product. And on reflection, if you're selling enterprise software, it's probably a good idea for you to consider this approach too (whether or not your product is open source).
Why do this? Are you crazy?
There are a number of reasons to consider taking this bold step - a step that many high-tech companies shun as competitively risky - and thus guard their roadmaps with absurd paranoia.
- Public roadmaps are consistent with openness and your customer community
I trust the customer/partner community, and they can only trust you if they know your plans. That way they are always involved in your development and you'll be able to best deliver meaningful new features, contributions, and roadmap suggestions. - Public roadmaps signal honesty and transparency
Transparency is key to building trust between partners. A public roadmap helps committers, partners and customers to know you're not pulling any punches with your direction. With transparent roadmaps, your technology partners know what to expect… and have a proactive vehicle to comment on the direction. - Public roadmaps are good to build customer trust
When customers buy into your platform, they’re putting their technology direction on the line. They want to know if you'll be evolving in the direction they want. For them, it’s all about mitigating long-term technology risk. This way, “opening the kimono” and boldly stating direction, is just plain good for the long-term relationship. - Public roadmaps show your pride, confidence, vision
Assuming you're proud of your engineering, and confident in your company, you should show it. Your thought leadership material ought to indicate direction - but put deeds behind words, and commit to technology direction following your higher-level vision. - Public roadmaps are good for businessIn sales situations, customers often ask pointed questions about specific (missing) features. And the usual answer “yup, we’re working on supporting it” is always received with skepticism. However, public roadmaps put your money where your mouth is… either it’s on the roadmap, or it’s not. And if the roadmap doesn't reflect mutual direction, work with customers/partners to change the roadmap… with everyone else to see.
Are you nuts? The competition will clobber us!
In reality, your competition is probably dealing with their own internal politics, debates and direction - and may not have time to seriously consider yours. And if they do take your roadmap into account, that generally indicates that they'll be a follower, not a leader.
OK, I get it. But what will Legal say?
True, your counsel will generally play the safe/conservative card. Their concern generally takes one of two angles: (a) Corporate liability if you somehow don't fulfill on your promises to customers and/or to the market, and (b) risk to near-term revenue by possibly stalling sales... if customers sit back and wait for you to actually deliver on the promised features.
To these, I respond with a bit of marketing pragmatism: First, you should always add some form of legal disclaimer to your roadmaps. Roadmaps are your best, honest intentions - but they're not guarantees... so say so. And, roadmaps have to do with *direction*, not necessarily with granular specifics - so it's OK to be vague and avoid details that could changes as development runs its course.
And regarding stalling purchases/revenue, consider this: If a customer is going to delay a purchase to see whether you deliver on a roadmap component, you probably run a greater risk of that customer going to a competitor in the interim. So I say, try to win them over *now* with your direction, and maintain their allegiance as you build on your roadmap.
Thoughts? In the theme of transparency, I'd love to hear yours !
Other Resources:
- We made our product roadmap public — and haven’t regretted it (Venturebeat)
- Radical Transparency: Our Product Roadmap Is Public And People Love It (ProPad)
- Why should you have a Public Roadmap and how to build your Public Product Roadmap (Holistics... with a nice list of public roadmaps)
(Note: A version of this blog originally posted March, 2019 on wso2.com)
Subscribe to:
Posts (Atom)