What is Product Enablement, and why do you Need it?

So one of my past roles was the Head of Product Enablement at a small US edtech startup, and that might be a title that’s unfamiliar to you. In this quick blog, I want to talk a little bit about this emerging field, what it actually encompasses, and why I believe that (my version of) Product Enablement should be a pillar of any product-led company.

What is Product Enablement?

You’ll find mentions of Product Enablement across the internet in various forms, but there’s not a huge amount of standardisation out there about what that actually means. So let’s try to come up with a single definition for what I mean when I say the words Product Enablement.

Product Enablement is the practice of creating learning and reference materials in order to enable staff, customers, and stakeholders to make informed decisions, improve processes, and communicate effectively and accurately about the product.

That’s as close as I can come to defining it succinctly, though there’s definitely infinite iterations on this that I could spend my time on. But it’ll do for our purposes. Product Enablement draws its name from Sales Enablement, which is a much more senior, defined term. As Hubspot puts it:

Sales enablement is the iterative process of providing your business’s sales team with the resources they need to close more deals. These resources may include content, tools, knowledge, and information to effectively sell your product or service to customers.

Product Enablement takes a step back and says “Wait, are sales the only people who need these materials?” because the answer is clear and obvious – no. Sales need to know what they’re selling, Marketing needs a source of product expertise to produce, review, and inform product marketing materials, Customer Success and support teams need to have an intimate knowledge of the product they’re supporting, and development teams need to understand exactly how parts of the product function, especially when it comes to onboarding new developers.

But this function typically falls in isolated business areas. Sales enablement focuses on sales, product marketing is a marketing function, documentation, training, support, roadmap announcements, developer engagement and relations – all of these areas that are fundamentally and philosophically doing the same job of product and company education are spread across as many departments and business areas as possible. The story of the product languishes in oral traditions, outdated docs, a lack of shared vision for communication.

Enter PENT

Product Enablement (or for short as we came to call it, PENT) is my attempt at fixing that, and I had the good fortune of working with a management team who were willing to indulge and embrace my weird ideas. PENT’s remit was simple. If it involves product education, knowledge, and memory, it was a PENT thing. This has a number of immediate benefits:

  • A shared product vocabulary – the language used when talking about the product can be more easily standardised and enforced
  • An internal source of truth – No more “who knows what this feature does?”
  • An internal source of expertise – No more using engineers or customer success to ensure the accuracy of sales and marketing materials and product announcements
  • Actual dedicated resource for ensuring quality customer, internal, and stakeholder education
  • The power of specialisation – Your best engineer is not your best writer. Your best product manager is not your best teacher.

By centralising everything, we were able to free up all the roles that normally get stuck with product enablement activities to do their actual jobs. As anyone who’s ever worked in a startup knows, time is the most precious resource, so why is it that so commonly you’ll find engineers working on documentation, CS teams training customers, and marketing teams begging someone, anyone, to review their product marketing materials for accuracy? What becomes the least-liked distraction for roles across the entire company becomes the focus of a single, unified department.

Why do we need Product Enablement?

But Matthew, I hear you cry, this isn’t a new thing! We have a documentation/training/developer relations/product marketing team who handle these things! To that I say that you probably honestly don’t.

  • If you’ve ever had a marketing blog go out that someone at your company who’s more in the know has gone “that’s not what that’s called/not how that works”, Product Enablement could’ve fixed it.
  • If you’ve ever had a sales team unintentionally mis-sell your product, Product Enablement could’ve stopped it
  • If you’ve ever had your backlog slip due to the weight of documentation on your development team, Product Enablement could’ve stepped in.
  • If you’ve ever had a new feature release without adequate training, documentation, and internal education, then you needed Product Enablement.

The problem suffered by almost all the traditional teams that I researched when proposing this department to my team is that particularly in large businesses, teams grow intensely specialised to the detriment of the wider product narrative. Training doesn’t speak to documentation. Documentation doesn’t have any insight into product management. And that’s not their fault – they are given a specific remit, and they are not prioritised or listened to. Nobody talking about the product talks to each other, and I find that deeply frustrating. By centralising product communication and enablement into a single department, those barriers break down, the silos empty, and you start being able to write and record (I’ll talk about writing and documentation a lot, but video is a crucial part of this remit too!) ahead of the needs of the company, using the people who have the most skills in content production and knowledge of your product.

This distribution is sometimes necessary for huge companies with already intensely siloed areas of business, I’m not saying this concept will apply at a Fortune 500 company. But for anyone in the small- to mid-sized bracket, PENT is the answer to “How do we make product communication, documentation, and training a central part of our business to ensure the success of our customers and expertise of our team?”.

Product Enablement Structure

I’m no expert in organisational structure, but I wanted at some point to fit in here what I think a mature product enablement team could look like for a reasonably large tech company.

Obviously, the smaller a company is and the less resources available, the further up these roles can roll, but these reflect generally what I believe to be the most important capabilities that should be present in a product enablement team, chiefly:

  • Product knowledge – the team should be up-to-date on all current and future developments, communicating with customer-facing teams, product management, and using their knowledge to feed back to those teams responsible. A dedicated product specialist could assist with sales calls with advanced-stage customers, write and review product marketing materials, and assist other roles within the team with content production.
  • Strong technical writing skills – internal, external, it doesn’t matter – what’s important is quality informative writing and communication skills that ensure resources exist when they need to exist.
  • Instructional design knowledge – Instructional design is a well-developed field for teaching, and there’s multiple levels of customer and internal product education that need it, from courses to tutorials and guides.
  • Training experience – Taking training workshops and webinars out of the hands of customer success and marketing so that they can focus on their actual jobs requires someone who can command the attention of an audience and speak to them as a peer, not someone who is trying to sell them something, or someone who’s also supposed to be trying to save a churning customer.
  • Asset production skills – Good enablement materials requires good assets, whether they are produced in-house or by external contractors. Video editing, graphic design, and copy editing are all skills that specialists have honed for years that do not require an in-depth knowledge of the material, but a strong enablement team needs to be enabled themselves to ensure their assets are as high-quality as is needed.

It’s entirely possible for all these to live in the body of one person, I should know – I can do all these things to some extent. But I’m not as good at video editing as I am at writing, and I’m not as good a graphic designer as I am at video editing. Everyone has a hierarchy of skills that they enjoy and specialise in, even if they wear many hats, and anyone who claims otherwise is lying. The bigger the team, the more roles can specialise, and a small start-up version of this may just look like 2 people with different combinations of these skills, or a single tired specialist trying to do everything themselves.

Interfacing with Other Teams

The entire point of Product Enablement is to extract enablement activities from other teams, not to silo them, but to expand their reach. This requires constant interfacing and communication with other teams, primarily:

  • Product management – Product management and enablement work hand-in-hand, to the point where you could quite easily attribute the responsibilities of product enablement to a product manager if you squint really hard. Product enablement requires a deep level of knowledge of the product, its direction, and the focus of its development to succeed. At early stages, product management will be focused primarily on the future of the product – how it develops and advances towards its goals – while product enablement will be focused on the present – how can what the product can do right now be better supported and communicated? With enough work and maturity, this relationship will shift to enable both areas to be future-focused – while product management makes the future state of the product happen, product enablement will make it successful and adopted.
  • Customer success – Product enablement lifts a burden that regularly falls to CS teams at small start-ups. Training, documentation, support – whatever distracts the CS team from focusing on their customers. In turn, product enablement communicates with CS regularly to gather insights on what customers struggle to understand, what features they’re under-utilising, what features they just don’t understand the need for, in order to plug the holes that stop customers succeeding.
  • Sales – Product enablement is also sales enablement, ensuring that the sales team have what they need to close deals, whether that’s bespoke documentation for new clients, other collateral, or simply attending calls with high-value prospects to answer their product questions tactfully and clearly.
  • Marketing – Product enablement doesn’t replace product marketing, the two disciplines are separate, but the line blurs, allowing marketing to have access to product expertise and provide product education as marketing. In 2024, people are sick of marketing. It’s a simple truth. We know it when we see it, and we don’t want to be sold to. But product education can market the product without selling, by answering needs that people have, particularly with products that have free trial or freemium offerings. Beyond this, PENT is a great source of blog content, white papers, and whatever other content will help get leads in the door.
  • Engineering – Internal developer documentation is still product enablement, and while nobody’s going to be as qualified as the engineer who built an API endpoint to initially document its capabilities, PENT can standardise, edit, and tend the garden of developer documentation. Instead of spending hours and hours not writing code, a developer simply has to explain to an enablement specialist how something works, write some rough notes, and leave the rest to PENT.

Wrapping Up

This blog’s long enough, and I could talk about this topic at length for another few thousand words, but I’ll spare your eyeballs for now and leave you with these questions.

  • What could your company do if you weren’t writing documentation all the time?
  • What could your product be if everyone understood it fully?
  • How much momentum do you lose from the people on your team having to work excessively hard just to understand your products?
  • Is your product knowledge siloed to the point where if you want to know something, you need to ask that one guy in engineering who could win the lottery tomorrow and disappear?

That’s the value of PENT. That’s why I believed it needed to exist, and that’s why I still believe it needs to exist. If you want to chat about this, I’m usually available over on LinkedIn, so hit me up if you want to hear an English guy waffle about consistency and knowledge sharing.

Share This Post
Have your say!
40

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.