Delivering public pricing to IBM Cloud
UX Architecture & Design
This project was conceived, researched, designed and delivered within 8 weeks and involved me influencing 11 product teams to get this built.
Problem
Due to a number of reasons, at the end of 2022 IBM Cloud removed its public pricing from the marketing pages of its products.
One of those reasons was that all our pricing was hard coded, so on an annual basis we had to refresh that content manually across 100+ product pages. This didnt scale.
This led to a significant gap, and in August of 2024, a large client asked for documentation on how to use our public pricing API to calculate their pricing. As a company we didnt publicise all the values needed to use this API and this was, as expected, frustrating for our customer.
My role & customer research
Having worked with this client before on a backup and recovery initiative I was asked by our senior leadership to find out more and see how this customer intended to use the API.
Customer voice
I hopped on a call with the customer team and was told they wanted to compare and plan pricing to get a TCO (total cost of ownership) for the services they were deploying. Specifically they were running a high peformance SAP HANA database.
In order to do this, they needed an ID of the pricing plan for each service they used and the documentation they were provided was too generic and didnt contain this information.
Existing feedback
This got me thinking - since we deprecated our pricing on our marketing pages over 18 months prior, we did not have any way for customers to compare the pricing of our services. So I went digging through the NPS feedback of our entire platform to find if other customers had raised similar concerns.
As expected - they absolutely had, however as the data had been spread out between multiple teams over the 18 months, it had not been caught as a systemic problem. This needed to be solved.
A couple of pieces of feedback we had received:
"IBM’s lack of public pricing limits our ability to estimate costs, making it a less viable choice for new projects."
"Without public pricing, it’s tough to budget and compare IBM Cloud to other providers."
Competitive research
How do other companies we work with go about allowing customers to price and compare across services in their Cloud platforms?
This needed to be done quickly as the customer needed to get this information back to their teams before the end of 3Q so they could plan their 4Q costs.
I spent the time to look at how other clouds price and show their tables, specifically around services that could be running SAP workloads. Azure, GCP, AWS and some smaller providers Hetzner and Digital Ocean all had a quick competitive research done on them.
Research synthesis
This all led to the following requirements / customer needs being identified:
- Our customers need a way to compare prices across the multiple pricing plans we have for each service and understand what pricing models we have on IBM Cloud so they can calculate their TCO.
- Our customers need to be able to grab the pricing plan ID's and be guided through the pricing API experience if they want to access this information programmatically.
- Our customers need to be able to compare pricing on an hourly and monthly basis.
- This has to be repeatable across all services on IBM Cloud.
Personas
The research resulted in this working supporting 2 key personas:
- Finops Managers (Alee)
- Infrastructure builders (Rohan)
Ideation
I needed to understand the way our pricing models work by spending some time looking at the pricing API that all our data feeds into.
Above is an example of the pricing API return when you make a call to the ID of the pricing plan.
From this I dug into the 11 key services as a starting point that our customer was asking for - we could make this work long term with more, but that was a good MVP.
From there I explored the different pricing models we have and found the following:
Linear pricing
This is simple pricing which scales with usage.
Example services: Boot volumes for VSI’s.
Flat pricing
This is a cost per hour / month model. Mostly used in services which have ‘instances’.
Example services: VSI profiles
Tiered pricing
This is pricing which might have an ‘included’ amount per month, or where at scale we offer discounts on usage.
Example services: Object Storage, File Storage for VPC
Related pricing
This is pricing which relies on another charge metric in order to calculate total cost of ownership.
Example services: Operating system cost in VSI’s.
Calculated pricing
This is pricing where two or more metrics need to be added or multiplied together to get a total cost of ownership.
Example services: Block storage for VPC, Cloud Object Storage
Wireframing
Jumping into some wireframing using these pricing structures as examples:
And then onto mid-fidelity sketches using existing coded components we already had:
When playing this back and speaking with the product teams who own these pages, it became apparent that we should be 'linking' to other services that are commonly used together.
By adding an 'optional services' section at the bottom of the page, this allowed customers to quickly jump to other commonly used products in order to get to the TCO calculation faster.
Putting this togehter this is what the tables look like in our product pages:
Making this repeatable
Alongside designing the custom pages for the initial services, I had to produce guidance that allowed our broader teams (100+ products) on IBM Cloud to replicate the tables for their pricing models.
I wrote and produced two guides:
- Services who's deployment experiences are auto-generated through YAML (eg. 3rd party or partner products).
- Services who have fully custom deployment experiences (mostly IBM owned services).
Looking to the future
The eventual goal here is to stop the 'wild west' of the pricing models we have within IBM Cloud. At this point in time this looks like making changes to the onboarding tooling we have internally to put guardrails in place so teams standardize on a format that can be understood across the entire platform.