Best Practices

Product Enablement – What, Why, How, When – and the Blockers

Published Jul 22, 2021

Starting a product-led culture requires a product enablement strategy — a process associated with training the rest of your company about your product. That’s right – it’s about raising awareness about your product internally. In this article, I’ll dig into the 101s of product enablement, such as the Why, How, When, and the common blockers when it comes to product enablement. 

Why is product enablement important?

Imagine having a product support group that’s responsible for responding to your clients,  but they’re unable to answer questions that require deeper knowledge of your product. 

All of those questions are usually funneled to the product manager. The more clients, the more questions — are product managers supposed to answer these questions or work on building the next set of features?

Equipping the different groups in your organization with relevant information about your product and actual hands-on experience with your product enables them to perform their jobs better and allows you to focus on your core function – building a better and more competitive product.

However, it’s not enough to just make artifacts and access to products available to everyone internally – it’s also important to make them available at the right time and with the right context.

How and when do you enable internal groups?

Engaging with different internal groups at different points of the product development lifecycle allows for this enablement to happen efficiently and in a timely manner. Here are some ways to enable internal groups: 

  • Involve sales, marketing, and account management groups during roadmap planning so that they know what’s coming down the line. It’s also a great way for product management to acknowledge that they have received the feedback from these groups and explain the prioritization thought process so that it can be communicated to both the current clients and prospects.
  • Involve technical groups (Prod Ops, SRE, Implementation Services) during architecture reviews that happen during the sprints so that they are aware of potential impacts to existing processes. Let them set up training and demo environments and keep these environments up to date as a way of becoming familiar with the technical aspects of the product. This also provides input about skillsets and bandwidth necessary to support this product.
  • Invite training and product support team members to participate in the QA of new features and solicit feedback. Many times, trainers are people who have been users of similar products or have performed the same business functions as your current users.
  • Update your usual documents – product guides, user guides, release notes, etc. But also create a product concepts document – this will help your own team members as a way of keeping track of how business definitions and processes change and thus generate the need for feature updates or new features in the product. It also establishes the context around each feature. Keeping these artifacts up to date is critical in ensuring that the rest of your organization is on the same page as the Product Management group.

What are the blockers to Product Enablement?

If you followed everything laid out thus far, life would be great especially if you were building a product from scratch. However, in many cases, you may be dealing with a semi-mature product in a busy organization. Here are the most common blockers you might be facing: 

  • Other teams are not familiar with your product and so you are frequently answering basic questions about your product. 
  • Your documentation is not up to date. 
  • There is enough tech debt that technical teams are busy fixing things that they do not want to attend your sessions.
  • You have important concepts about the data and the product in your head because it may not have a place in the user guide. 

Paths to success

Unfortunately, there is no silver bullet – it depends on your organization. Here’s what you can allocate time to: 

  • Allow the Engineering teams to make operations more robust
  • Re-architect processes to remove redundancy, confusion and reduce cloud costs
  • Put constraints in JIRA to ensure that there were updated artifacts before declaring a release deployable 
  • Move QA from engineering to product
  • Allocate time in your release cycles to enable other teams to set up training and demo environments
  • Log feedback from training as bugs and improve your Regression test cases which in turn make the product more robust. 
  • Publish a product concept document that includes information about data provenance, Conceptual ERDs, and information about specific interactions between different products developed by your company if your product is part of an enterprise suite.

The flip side of ignoring product enablement is that your organization becomes completely dysfunctional when it comes to your product and then it’s a downward spiral from there. Enablement must be specific, relevant, and timely for it to be effective.

At the end of the day as a product manager, you need the support of the rest of your organization to sell your product to new customers and renew licenses with existing ones. The first step to doing that is ensuring that your organization is knowledgeable about your product which in turn allows you to focus on product development in response to changing market needs.