Are your processes ready for PLG?
Assess if your organization is ready to implement product-led principles
After the 2-part mini-series on “Where to start applying PLG” (Part 1 & Part 2) we have a good sense of the most suitable place to start applying PLG, and we understand how big a change this will be to your current Go To Market approach.
Next, we need to assess if the way your company develops products is well prepared for a product-led operation. The questions in this section will help you assess if you have the right people and processes in place to effectively run a PLG motion.
Becoming product-led increases the required level of professionalization for many processes, from product strategy, to product delivery and the role of analytics in decision making.
It’s important to understand where your company is today so you can identify where you might need to change existing ways of operating. And if you feel you are too far off, you can even make the decision to initially have new product experiences developed by an external team to de-risk the delivery.
Roadmap
As in the series mentioned above, we’ll have a number of questions to go through which will give an indication if there are any challenges to implementing PLG in the organization.
The first part focuses on the process around the product roadmap. Let’s start with the questions:
Q1 – Do you use product metrics to assess if a customer gets value from their contract?
For example, usage metrics, number of users, and value events, which could be part of a health score Customer Success uses
Yes
No
Q2 – Do you have a matured feature request process?
Is there a process to request and track features requests from customers and colleagues?
Yes
No
Q3 – Would you say your roadmap prioritization is typically more short-term or long-term?
Short-term would be a roadmap driven by C-level input or requirements for open opportunities, long-term would be to serve groups of customers better or engage on new market opportunities.
Short-term
Long-term
In essence the above questions assess how much information the company collects from customers to drive the product roadmap.
On one end of the spectrum is the ultimate quantitative approach, that tracks product usage, collects customer feedback at scale, and prioritizes based on this information. On the other side is the more top down approach where for example a CEO sets direction for the company and the only measure for success is revenue growth.
An organization that prioritizes the product roadmap based on open opportunities with customers will struggle more with product-led principles than a company that’s used to prioritize based on aggregated customer input and usage metrics.
That’s because to become product-led, you’ll need to standardize the experience for the customer. The goal is to find the commonalities between what all (or certain groups of) customers need and building an intuitive experience to provide this value. Developing one-off functionality for a single customer is therefore quite uncommon in PLG.
Product delivery
After the roadmap we’ll assess how new product functionality gets delivered.
As we’ve learned, one of the keys to the success of a PLG motion is to keep iterating on the experience to optimize the user journey towards the desired result.
Therefore, understanding the current practices in terms of delivery helps us understand if the existing process will be ready to facilitate this.
Q4 – Do you follow an iterative release process today?
For example, if you use Agile or work with Continuous Delivery, but really any process that delivers a product step by step and measures results would count.
Yes
No
Q5 – Do you have user quality gates when releasing new features to customers?
Do you for example have a process to get live feedback from customers before releasing broader, or do you release to smaller segments first and monitor adoption?
Yes
No
Q6 – Do you track the effectiveness of new features?
Do you for example monitor usage metrics and/or recordings after release of the feature or A/B test most important changes and decide based on the data.
Yes
No
The spectrum on which we are measuring your company in these questions is comparable to the previous section on Roadmap.
On the one end of the spectrum we have a company that only releases a new module after it’s been developed in full and doesn’t have use quality gates in place. Basically, the main driver for release to customers is approval from a key stakeholder.
On the other end, we have a company that first releases an MVP and then iterates on this by rolling it out to specific customer segments and assessing the customer feedback and usage data to understand if it is having the desired outcome.
The closer your company is to the latter, the readier you are to adopt PLG. This doesn’t mean that your company cannot do PLG if you don’t have the processes in place to support it.
In that case it would be advisable to have this team operate separately from the regular engineering processes, or even have an external team do the development, so you can create the first wins for your PLG efforts and gain momentum to drive change in these processes.
Technology and Scale
Beyond the delivery process we also want to assess if the existing state of the technology and organization is well-suited to support a new initiative like PLG. Two questions will help us explore this:
Q7 – Does your company stay up to date with modern technology?
This doesn’t have to mean that you use the latest technologies and frameworks but it should be modern. If your company uses outdated technology that should be replaced but still works, answer No.
Yes
No
Q8 – How many engineers does your company have?
Less than 15 people
More than 15 people
We already touched on the release process in the previous part. Another dimension that’s an important indicator for the ability of the organization to adopt something new like PLG is the modernity of the existing technology.
A company that has more modern technology, generally tends to also use more modern development practices and can be expected to be more open to further iterations of that in the context of PLG. A company that uses date technology and potentially more traditional development practices will struggle more with this.
The size of the engineering org gives an indication of the capacity to dedicate resources to PLG efforts. Teams of less than 5 people would potentially need the company to fully dedicate to PLG to be able to execute, whereas larger organizations could assign a team of a few developers while keeping the usual operation unaffected.
Data analytics
The last two questions give us a sense of how common data-driven work is within your company:
Q9 - Is your company data-driven?
Are important decisions supported by a thorough data analysis? Answer no if management of key stakeholders typically make the decisions without data as a part of the consideration.
Yes
No
Q10 – Do you have an analytics function?
At the very least this means you have analysts employed in the company who look at the data. Ideally this means having an analytics function and specialized analysts per function.
Yes
No
In this case, on one side of the spectrum of possibilities we have companies that are top down and where no analysts are available. These types of companies will face bigger challenges when operating a PLG model as the data-driven approach is a core part of this.
On the other end of the spectrum we have companies with a matured analytics function and where teams are encouraged to analyze data and adapt their approach based on this.
Even if this department doesn’t include a product analytics team yet, it will be easier for the company to adopt the data driven foundation of the PLG approach, because many of the foundational principles and infrastructure will already be there.
What’s next
You can use the assessment above as well as the PLG Compass to shape your view on how PLG can add value in your business and what would be the best approach to implement it. Let me know in the comments how this works out for you!