"Skin in the Game" Product Development Models
"After all, the hardest part of the product side of platform engineering is figuring out usability."
- Camille Fournier
"One difference with PM for customers within an organization compared to PM for an external product is that you have the opportunity to solve more completely for your business problems."
- Nick Brett
Early in my research on product management for internal developer platforms, I read this article by Camille Fournier. Besides broader knowledge, I was also looking for specific patterns to apply and found two particularly instructive for internal product PMs.
In this article, I want to dive into two beneficial models to be aware of: "Partner to Prototype" and "Assimilate and Expand." And to talk more broadly about the benefits of "Skin in the Game" product development models.
What are they?
Assimilate and Expand:
Camille writes: "... so how do you find a successful product? Don't be ashamed to take over a system from a team that built it with themselves in mind, if that system seems to be the right general concept for the wider company."
"Assimilate and Expand" involves finding a solution that a customer team has already built and uses, then extracting and expanding that product to fulfill a more global need through the Platform.
She notes it's a unique skill to practice: "There is a lot of interesting work in taking a solution that is locally-optimized and turning it into something that can be used by a diverse set of applications." implying there is a process to refine around the model.
Partner to Prototype:
"Another way to identify promising new opportunities is to partner with another team, and even embed someone into that team, to understand a problem better. Partner teams are likely to come by and ask if you are planning to build something to solve their various problems. When you believe that this is a good specific example of something that will become a general pattern, take advantage of this request to learn more!"
Rather than identifying a solution that a team has already built, "Partner to Prototype" involves building a greenfield Platform solution with a customer.
Skin in the Game Models
The common element in both patterns is that engineers from customer teams spend time building Platform-adoptable solutions with you, or customer teams have "Skin in the Game."
Here's why they're valuable
They validate a problem essential to solving. The problem is so painful that they will "pay" for it. Engineer time is currency. A team allocating engineers to solve a problem is equivalent to a customer giving us money (same for time spent to adopt a solution by choice).
They validate a solution through adoption. "Assimilate and Expand" starts with an already satisfied customer, and "Partner to Prototype" ensures a happy customer at the end due to co-developing the solution. Adoption is challenging for many internal developer tools, but "Skin in the Game" models either begin or end with at least one customer adopting the solution. As a bonus, they often act as champions for other customers to hear and see.
Overall, this results in faster delivery with fewer mistakes. Traditional product development practices for internal product development incur risk and coordination costs when:
Identifying the problem
Designing the solution
Gaining adoption for the solution
Even one mistake removed from the discovery, development, and adoption pipeline pays returns.
What's Next?
These are so valuable that opportunities to add "Skin in the Game" by using patterns like "Partner to Prototype" or "Assimilate and Expand" as enhancements to the traditional product management workflow. They are skills to practice, and there are more patterns to discover.
Another pattern I've seen to introduce "Skin in the Game" culturally is with open-source models. Teams can submit PRs and behave more asynchronously while still "paying" for product changes. From a PM I spoke with, this is seen as a more equitable approach since it doesn't rely on acquiring Platform engineering time to produce changes, which lower-priority teams will seldom receive.
Whatever the pattern, leveraging the ability to bring in the customers as paying partners early on is a more efficient and effective path than simply mirroring traditional product management processes.