Hi all currently I am in the need to develop a “pricing strategy” for our developer platform so we can charge our org business units for their platform usage, does anyone have resources and best practices that could help me with this

I have so many questions... starting with why does the org need to charge for the developer platform? Is there a successful history of a chargeback model in your company? How would you describe the value of the platform to the organization? How would you quantify the costs of the platform?

No answer to your question, sorry 😞 but I'm also very interested to hear more about what's the motivation behind charging BUs for the usage thinking wouldn't it hurt the adoption (which is usually an issue anyway?)?

I would want to presume that you have sufficient resource tagging and domain engineering implemented. Secondly, if your platform capabilities are exposed via APIs, you could explore using number of API calls as a charge back mechanism. Thirdly and most importantly, have you explored the route of building a capability positioning board for your platform following a standard product positioning template? This could help you to communicate the value and viability of your platform well before going the service pricing route.

I’ve seen such an approach of allocating costs between internal teams. It wasn’t only for platform products, but for virtually everything. E.g., allocate the costs of running Jenkins and costs of Slack licences for your team. The main goal is to have transparent budgeting. All of it works by a lot of tagging and assignment. Teams that own platform products figure out the allocation strategy and send data to an in-house product. All of that worked reasonably well, but took quite some time to implement.

Hey all thanks for the quick replies, I am not familiar with standard product positioning template and how that would be a replacement for the service pricing route @Geeques

@Erick Aguayo aah aah, the background context helps, I don't think you need a positioning doc in your case. I mentioned the use of the Product Positioning document because I assumed that you still needed to build some confidence and adoption via internal marketing within your development teams; but I see that you have already have your market hooked.

I often recommend this book on pricing to clients: https://us.macmillan.com/books/9780809078813

your options exist along a spectrum between: • aggressive fine-grained tagging of every individual cloud resources a BU uses, which is then used to pass along the underlying cloud pricing to the originating BU. ◦ pros: everyone is responsible for their own operating costs. your BU's additional cost is the overhead of funding the team that does platform maintenance. ◦ cons ▪︎ other BU's now have to do their own spend projections ▪︎ everyone's life is more complicated because chargeback is modelled in every platform abstraction ▪︎ how do you do spend reconciliation if there's a bug in the tagging? ▪︎ unclear how shared resources will be billed (e.g. if you use a 3p SaaS that doesn't propagate resource tagging into costs - Sentry for example only recently released Spend Allocation) • set up an internal SaaS model, where your BU charges the other BUs for their usage of your platform. ◦ this still requires some amount of usage tracking, but doesn't necessarily entail tagging underlying resources with the consuming BU. ◦ pros: your users have a vastly simplified view of pricing ▪︎ provides a mechanism to manage spend for shared resources. ◦ cons: ▪︎ your BU needs to do a lot of cost/spend projection work ▪︎ you still have the spend reconciliation problem where you land on this spectrum (alt: what costs you abstract away and what costs you directly pass along) is entirely dependent on the abstractions you have for usage tracking (if you have any - it sounds like you don't), the timeline you need to deliver on, and probably most importantly, the people responsible for managing your company's spend (finance/accounting) and what they need to see from you. also, what happens if a given BU exceeds their budget? should their services hard fail, or is it OK if that cost is absorbed by other BUs? (the answer to this will depend on the magnitude of the overrun, but it has pretty big technical implications)

If the usage patterns of your customers have a big impact on how much money they spend (e.g. because they get access to a dedicated Azure Subscription/AWS Account), I would recommend to chargeback • the costs of underlying resources (e.g. the whole Azure Subscription/AWS Account) • plus (optionally) a fixed fee for a “tenant” on your platform • plus (optionally) a percentage of the costs of underlying resources

I keep thinking about this question. While @Samuel Lijin makes some great points about things you might think about down this path, I'm still not sure that chargeback is the best funding model regardless whether it is passthrough-resource-based or abstracted as a service. Mostly this comes down to me being wary of the fact that incentives drive behavior and that taking a cost-based view will cause certain behaviors to form that may be constraining in the future (think enshittification of the platform). What benefit does the platform bring to the organization? How are other cross-cutting concerns, like your security team, funded, and why is this different? If you weren't located in a specific BU, where would your team ideally sit in the org? How would you define your north star? I wish I had answers, but the best I can offer is questions! :)

Hmm… this is such a dynamic and explosive topic 🙂 What has worked for me in the past - caveat… obviously that was bound to the org it was running in. If your org is hugely different, then it might just not work. 1. Install chargeback for things the platform creates - you create infra… you pay for it. 2. Don’t implement chargeback for the platform - simply that. 🙂 Why no chargeback on the platform? Normally BUs fight for their budgets at least once a year and then get to spend them how they were requested. If you want another BU to cross-finance your platform, then this is a matter of one of two things happening: 1. Your own BU requests more budget because your platform is used by other BUs - you get your budget. Everything is good. 2. You make other BUs request budget for platform usage and make them allocate it so you can use it. You get your budget - everything is good. Having this over “running costs & chargeback” is usually much better because you can reason over FTEs/positions that you can finance with available budget in a nicer way. So what would motivate another BU to actually do that? Getting a seat at the table. You only use and do not contribute by acquiring a budget? You get no say or priority in feature requests, direction or anything. That way you have “the big fight” on the management level where it belongs without any impact on the platform or it’s users. Adoption is not hampered by making people decide badly because of budget usage. BUs are still held accountable for resource waste - they pay via chargeback after all.

Getting a say in how the platform is developed by allocating budget so the platform team can use it is an interesting approach that I haven’t seen “in the wild” yet. Thanks for sharing! What I’ve seen most often is charging back only the infra created by the customer and carrying the “overhead” completely within your team. I have seen a few companies where they are charging back the platform based on usage and even negotiating/offering usage discounts for their bigger customers, like you would do with public cloud providers. In the background there can still be committed budgets, but the amount is based on usage forecasts.

Hi @Erick Aguayo, Only seeing this now.. I'm currently facing the same issue and need to develop a pricing/chargeback model for two scenarios: 1. Our platform, initially developed by our BU, has gained interest from other BUs who prefer using it over building their own. We need a model where they pay for what they provision, possibly with an allocation key based on consumption figures for shared costs, and a fixed price for support. 2. Within our own BU, we want to virtually charge our teams to help with decision-making and understanding product profitability. Currently, infra/platform costs are not easily allocated across products, leading to poor infrastructure choices for new products. I'd love to discuss this further as it's one of my Q3 objectives.