How to Start an Internal Product Adoption Plan
As an Internal Developer Platform PM, if there is one thing you'd put more focus on for your following product, what would it be? PMs I've spoken with -- from Stripe to Microsoft -- say they would start the adoption plan as early as possible, even as a part of the product vision or initial strategy.
Gaining adoption is always a struggle, yet essential. An adoption plan aims to ensure the product gets leveraged. No adoption, no return on investment. But what are the components of an adoption plan?
While browsing Slack, I came across this comment to a question asking about strategies to increase adoption in terms of the number of teams onboarded (bolded parts by me):
“Adoption isn't the goal. It's the mechanics of getting an outcome your organization wants.
I find it best to get buy in on the outcomes and then work out the mechanics of getting the right adoption rate based on cost of delay.
The three main outcomes I've found that buy in is clear on are:
reduction of KTLO/maintenance work, because it frees up more time for product work
delivery speed increases, because things you could ship before in a week you can ship in two days now, and product values that
it's safer to move faster, because production outages or security breaches kill both productivity and customer relationships, and product wants that”
- Nadav Cohen
Nadav touches on a few crucial points: adoption is just a means to an end, and agreement on the adoption timeline is unique to each product team.
Adoption is a Proxy Metric
Adoption is a standard metric in product frameworks (i.e., the HEART framework) because it's usually easier to capture than specific outcomes, but remember, it's a proxy metric.
The beginning of any adoption plan starts with clarity on the expected impact on outcomes for the customer and the ability to use adoption as a proxy to signal general progress. Nadav points out three primary outcomes:
Reduce KTLO/Maintenance Work
Reduce Security and Reliability Issues
Increase Delivery Speed
I'll add one more that gets used in modernization initiatives:
Reduce the Financial Cost of Technology
Besides what Nadav writes, there's also financial improvement and profitability outcomes. For example, at Twilio, we're gaining adoption on a Platform that utilizes cloud computing more wisely to decrease the financial cost of running applications. That alignment is an incentive for teams more focused on profit than others.
Help the Customer Determine an Adoption Timeline
The value of adoption is relative to the customer, and it's the PM's job to help them understand the cost-benefit of delaying adoption. The cost of postponing adoption will be different from team to team. We want to ensure we serve the organization's broader goals first, so each product team is unique regarding their capacity, priorities, and the cost of delay.
The goal isn't to coerce them into adopting but to help them find the right way to spend their resources to benefit the organization. If we can model the cost of delay for the customer team or make it easy for them to do so themselves, then customers can determine rational timelines for adoption.
A list of initial customers specifying which quarters they'd be open to adopting the product while pitching for funds or aligning teams act as extra capital.
The Components of an Adoption Plan
So we see two components so far:
A description of the outcomes the product will impact.
A list of product teams with potential adoption timelines.
But a third component isn't covered here: making adoption as cheap and accessible as possible, which will be my next article's focus. Often, teams will only adopt if the DX is manageable. If a customer team lacks capacity or the DX to adopt is painful, the cost increases relative to the outcomes they hope to achieve.
A significant differentiator of value in Platform departments is making the adoption of new things as cheap as possible. Product teams almost always want to adopt new platform releases, but resource constraints and product features always exist. The more seamless the adoption, the better off the organization will be.
What's Next?
A significant variable we touched lightly on is the cost of adoption itself. How much does the adoption cost a team? Can we make adoption cheaper and more accessible, and if so, how does that change when teams adopt new features or products? In the following article, I'll dive into practices organizations have used to make adoption more affordable and accessible.