Kara Gillis

There are several inputs I think about when considering product differentiation: 1. Specific target customer - There are many types of customers in a market. Who are you serving? Try to narrow your focus as far as you can to understand the specific problems faced by this customer to be as tailored to their needs as possible. Has a particular customer type been ignored or underserved in the market? If so, why? What value are they seeking but not able to find with existing products? 2. Specific value delivered - The inherent "why" customers use your product. Regardless of how many features/"bells and whistles" you think customers want on your roadmap, there are generally much fewer reasons why they use your product. What is the CORE reason? That is your moat. Stengthen and defend this core value proposition to the best of your ability before adding more stuff. This value is the point of view you solve your customer's biggest problem - don't lose sight of it, or you'll start solving problems that don't matter. 3. Market maturity - Is this a new market? Is this a mature market? Hugely different considerations. In mature markets, the incumbents have defined what good looks like, or what customers expect. Incumbents will lage behind new entrants in not adapting quickly enough to new customer expectations, and new entrants may not accommodate the existing requirements fully enough. This is a hugely delicate balance to strike. This goes back to #1 - who in the market are you serving? Then, adjust accordingly. 4. Competitive benchmarking - You have to know why your customers choose other vendors. You have to understand why sales loses deals to these competitors. What value do they derive from these vendors. This is more of a general understanding of where you fall in the market to understand if there is a difference between your positioning and market perception. 5. Ease of use - Making something easier to use is itself a product differentiation strategy. I like to think of the two axes here to be - 1) how powerful is the product and 2) how easy is it to use? - and then determine where my product falls within and these two axes. Upper right quadrant - easiest to use and most powerful. Highly differentiating, but pretty rare. Go back to that target customer - how technical are they? What do they care more about? What do other solutions make hard for their customers that I can reduce as a pain point? Apply. 6. Pricing and packaging - This could be an entire AMA itself. Think of pricing as another way to leverage strategy. Charge for the value delivered in the product. What do I mean by that? Charge more when customers get more value out of the product, so you align product incentives with your customers. The trick here is to pick the metric that best represents value in your market, for your customers. Options? # of users, # of things in product consumed, # of things I can apply the product to, etc.

I used to be a product marketer. My ideal working relationship is to view product marketing as my key partner in product development, launch, and iteration. We are both stewards of the product success. I try to involve product marketing into the very beginning stages of product development - they help me amplify the voice of the customer, help me find reference customers by launch, fine tune messaging, speak to industry analysts educating them on the new product, enable sales and customers on the product benefits and messaging. PMMs also conduct competitor messaging/positioning analysis, deal win/loss analysis, and in my experience, how the product is represented in all facets (website, content marketing, customer facing slides, analyst research).

This is a tale as old as time. There are many ways to approach this. I have seen vendors heavily bid on the AdWords of their competitor names and promote alternative solutions (trials or marketing content). I have seen vendors who are challengers in mature markets create "Us vs. Them" web pages or blogs that outline the differences (according to the vendor publishing the info) what the major differences are. And, I have seen third-party research or analyst evaluations heavily promoted that rank vendors according to specific criteria (contracted by the vendor or annually conducted created by a research firm). However - the most powerful thing I see is customers doing the work for you. In general, I'm not a fan of tearing down competitors publicly. Think about a time you heard a friend talking about someone behind their back - it makes you feel uneasy, maybe even distrustful of your friend, right? Now think of the inverse. What if you heard you friend tell you a positive anecdote about a service or new app they used for a problem you have. How likely are you to try that service/app? I believe positive associations are more powerful than negative associations for long term engagement and trust. Customer stories are your biggest ally here. Maybe you can include in the customer story that Customer A replaced an *unnamed* competitor with your solution, and UNLIKE *unnamed* competitor, they derived the following three benefits and business outcomes with your product. And now you can arm your sales team and/or partners with this story to have a specific "you vs. your competitor" conversation with one customer at a time, proven out by a trial or proof of concept. Put your customers on your website, have them speak to other customers (video testimonials, backchannel phone calls, on stage at your conference, etc.). Customers are your biggest offense against competitor messaging. 

I typically advocate for using full-time engineering talent on the most innovative features, hardest problems to solve and outsource to third party services for things that I can depend on, not require a ton of updates to, and save me money. Your dedicated engineers are there because they're your most valuable resources - keep them engaged and excited by working on the most fun challenges!

I think you say exactly that! "We're pivoting our product. There are a lot of unknowns. It's hard to plan our roadmap too far out. We're resetting expectations on how much we can communicate..." THEN, I would add this... "We are focusing on these 3 themes in this priority - 1... 2... 3...Our goal is to deliver these X, Y, and Z customer outcomes by pivoting our product. We plan to have an update on these themes in ABC timeframe." It's ok not to have all the answers in times of big change and ambiguity. If you did, you'd probably be guessing at best! And that's the fun - figuring it out.

I tailor the product roadmap to the person / group with whom I'm communicating. I often will use Google Slides for a customer or sales facing presentation. With engineering, I'll often use a spreadsheet that lists roadmap initiatives in the order of priority and effort. Communicating with customers: Is this the first time we're speaking? How much time do we have? If it's the first time we're giving a roadmap presentation to the customer, I provide more context upfront to help the customer understand how the roadmap impacts them directly. I will include some slides on the pain points and market trends that I'm solving for, map those pain points to high level overview of the roadmap themes, and then highlight our most applicable major features (and the customer benefits of the feature) in a little more detail, typically one per slide. I also make sure to provide a rrough timeline (3 months, 6 months, 12 months) for any feature I cover. If it's not the first time I've spoken with the customer, I focus on what's changed / newly delivered in the product since the last time we spoke, specific updates to the roadmap that would be applicable to this particular customer, focusing on one major feature area per slide (and including the benefits of the feature!). I will sometimes include success stories of existing customers to demonstrate real world examples. I then welcome questions after major sections of the presentation, for example after each feature or after pain points to make sure we're aligned on the same premise before diving into features. Communicating with non-technical sales: Almost exactly like the customer version, but I spend more time on how the roadmap items impact pricing, packaging, integration with existing products, and updated timelines. I also spend a lot of time on how to communicate the benefits of each major roadmap item in concise and clear language, so it's easier to convey to the customer. Communicating with technical sales: Very similar to non-technical sales, but maybe a little bit more about specific capabilities, scale limits, compliance, or backend updates/updated tech debt that fix internally-known product issues. Technical enablement on new features and roadmap items will also focus on HOW to implement the feature. Communicating with engineering: Usually done as part of planning, it's important for engineers to understand the "why" behind anything they will be decide "how" to implement, and the more context they have about the "why now" reasons behind a feature, and the requirements about "when" - the more likely you'll deliver an accurate roadmap! Engineers care about many things regarding the roadmap, but understanding your priorities and required timelines are paramount to help determine the scope of the work and any dependencies you may have in implementation.

In a perfect world, you want at least 80% of your roadmap to be applicable to both! But, we don't live in a perfect world, do we? Some startups focus on a small number of customers and really customize the product to the desired features of those early users, but I like to first go broad in appeal, and then deep into a few features that are highly impactful to as many users as possible. If you want to reach a new type of user, solve a new use case, or enter a new market, you will have enough of a reason to build something exclusively for prospects. This is a strategic decision to expand your business or market footprint. A great way to determine if your roadmap is mostly applicable to both prospects and existing customers is to build a way for existing customers to submit ideas for the roadmap, and let your entire customer base upvote their favorite ideas. The more votes, the more likely both existing and new customers will benefit from the roadmap idea. Sometimes, however, you'll have a big customer needing something specific, and there will be many reasons to build something unique, often influenced by the size/revenue impact of the customer. I don't usually let more than 5-10% of the roadmapa focus on one-off, custom features.

Executive alignment on your roadmap is pretty key to getting funding and resources to deliver on your roadmap. Your executive team probably cares about customer success, growth, and potentially things like margin/security/compliance. Tie your roadmap to these outcomes very clearly. If you can communicate very clearly HOW your roadmap item helps achieve more than one of these outcomes / benefits, you are more likely to get buy-in. What happens when you disagree with the executive? Well, that depends on whether the exec is challenging your roadmap prioritization to understand where you're coming from as a mechanism for providing feedback OR if the exec is communicating a mandate to accommodate a strategic initiative. There's a difference. For the former, you can make sure to communicate how your roadmap helps achieve those desired outcomes. If the latter, accommodate away.

While I don't use an existing framework specifically for product differentiation, I do use a variety of inputs to determine what lever to pull or what decision to make. These inputs can be found in the answer to the question, "What are the most important inputs to take into consideration when thinking through product differentiation?" Other frameworks I do use: 1. Geoffrey Moore's Positioning Statement Template in his book, Crossing the Chasm: "For (target customer) who (statement of the need or opportunity), the (product name) is a (product category) that (statement of key benefit – that is, compelling reason to buy)." 2. Gokul's SPADE Decision Making Matrix (thank you to a former Square employee for introducing this to me at a recent networking event): https://coda.io/@gokulrajaram/gokuls-spade-toolkit

Prioritization is more art than science. My goal is to actively listen to all stakeholders and help communicate how I make tradeoffs and how that impacts timeline to deliver a requested feature. But as a rule... Customers have the most impact on roadmap. Then engineering (especially on tech debt, architecture, compliance, and quality improvements needed). Then, I weigh any influence from market trends and changing competitive landscapes. Here, I consult with analyst relations, product marketing, and competitive intelligence. Then sales/CSM/support to learn trends/issues they're experiencing directly with customers or issues selling. And sometimes, executive input will trump everything else - but that doesn't happen as often as you'd think unless you work in very top-down work culture. Ultimately, as the product manager, it is your job to make the final call on the roadmap prioritization. It is your primary responsibility!