The m3ter Origin Story: Why We’re Simplifying UBP

As founders, we worked closely together for 15 years before starting m3ter. Originally, we had a supplier/customer relationship. Then, we founded a startup together in 2012. We sold that to Amazon in 2017 and worked closely together at AWS – and we learned a few things during that time.

Chief amongst these is that sharing the same, slightly unusual name brings complications. One of us is John Griffin. The other is Griffin Parry. We get each others’ mail. A lot. 

But we also learned a great deal about the challenges of deploying and managing usage-based pricing (UBP). We thought about it, talked about it, complained about what was missing, and dreamed about how the world could be better for software companies if that gap was filled. The origin of m3ter is rooted in these experiences. 

Let’s go back to the beginning.

GameSparks 

In our pre-startup lives, John was a data engineer, and then progressed to leading sales and marketing for a successful UK systems integrator. Griff had a career in media focused on strategy and digital products, and we met when he appointed John’s company to build the online TV platform at Sky in the UK. 

In 2012, we took the plunge and founded GameSparks, a backend-as-a-service for video games. We had a Product-Led Growth (PLG) approach, allowing games developers to self-serve on the platform, then targeting sales effort at the most promising to expand their adoption or secure commitments. 

We chose to use UBP because it suited our customers and their imperatives. Developers could sign up for free and pay us based on the number of players their games achieved. This was good value-based pricing that allowed for big upsides: when the developer was successful, they paid us more, and were happy to. And it eliminated adoption friction, allowing for widespread evaluation and use. 

The business was successful, establishing category leadership and attracting hundreds of paying customers. We were acquired by Amazon in 2017, who already used our service to support their own games studios, and saw it as an attractive potential addition to their portfolio of AWS services focused on the games sector, alongside Amazon GameLift and Amazon Lumberyard.

But our use of UBP wasn’t all smooth sailing.

1. We had billing operations pain. We had a spreadsheet-based manual system to bring together customer usage with commercial terms (which were often bespoke per customer) before passing calculated bill amounts to our invoicing system. This was painful and error-prone, and we struggled with complexity and scale. 
2. We had CX (customer experience) pain. Our customers wanted to be able to monitor what they were using and how that drove their bills. We couldn’t deliver that, either self-service (which would have been ideal) or via a customer support call. 
3. We had Sales and Customer Success pain. Our teams needed up-to-date information about a customer’s usage and billing to inform conversations with them, and this wasn’t readily available without disturbing the engineering team.
4. We worried about customer profitability. We had significant variable costs driven by customer usage, and our pricing didn’t perfectly align revenues with those costs. This meant variable margins per customer depending on their usage patterns. We wanted to monitor per-customer unit economics closely but could only do this with infrequent, manual, messy spreadsheet-based analysis.
5. We struggled with budgeting and planning. Because our revenues (and costs) depended on customer usage, we couldn’t forecast with confidence, and that made planning and investment decisions stressful. 
6. We knew our pricing wasn’t optimised. We did a lot of bespoke pricing, and also tinkered with our public pricing. We did OK, but we knew we were leaving money on the table and that improvements – if only we could identify them – could potentially add hundreds of basis points to our bottom line. 

AWS

After being acquired by Amazon we worked as product and GTM leaders at AWS. 

AWS is one of the world’s great companies – the leading public cloud provider which has facilitated a wave of innovation and modernization across a whole slew of industries. It is synonymous with building a software-powered business – “the AWS economy”. 

It is also, crucially, a pioneering user of UBP in the tech space: customers pay AWS based on how much resource they use. Reassuringly, we discovered that they faced all the same UBP-related pain points that we had had at GameSparks. The difference was that they had the time, resources, and ambition to build tooling to address those challenges. We got to see it, use it, and benefit from it – in other words, we saw what good looked like. 

For example, they have developed:

• a core metering and rating engine that flexibly supports complex pricing and aggregation schemas
• a ‘customer insights’ tool that gives customer-facing roles near real-time information about the usage and billing of their customers
• the ability to forecast revenues by applying data science to usage signals

And it wasn’t just what they built, but how they built it. AWS can be seen as a collection of 200+ semi-autonomous services plus a group of shared services that support them all. This means their shared services tooling needs to be ‘productised’ such that it can be used effectively by multiple independent internal customers. It also needs to be built for the highest level of operational excellence, and for extreme scale. 

And now: m3ter

Amazon prides itself on its ‘builder’ culture, meaning it provides a great environment for people who see problems and are motivated to solve them. We have those inclinations, which is why we liked it there, but also why we felt the urge to leave - we wanted to get back in the game and build a new company, bigger and better this time.

We also knew what our mission should be: we wanted to enable other companies to intelligently deploy and manage usage-based pricing. We’d experienced first-hand the pain points in a fast-growing startup. Then at AWS, we were inside an organisation that built great solutions for these problems. We wanted to make these available to all software companies.

We were confident there were a lot of companies out there needing the help. Another benefit of our time at AWS was that they have a large and fast-growing customer segment made up of SaaS businesses. We worked with many of these, and found that the UBP-pain points we experienced at GameSparks were absolutely commonplace.

We were also confident that demand would grow, based on a trend towards UBP in software pricing that is accelerating as pioneers show spectacular results. Consider this: SaaS businesses with usage-based pricing are experiencing 29.9% year-on-year growth compared to the 21.7% of the broader SaaS space, and net dollar retention (NDR) of 120% compared to the rest of the industry’s 110%. And seven out of the nine SaaS IPOs that had the best NDR in the last few years – the likes of Snowflake and Datadog – operated UBP models.

As a result of this growth and best-in-class NRR, usage-based public SaaS companies are valued at a substantial premium compared with the broader SaaS index, with average revenue multiples at 21.6x vs. 14.4x, according to OpenView Partners.

How m3ter does usage-based pricing

We had a particular point of view based on two key insights. Firstly, that the current quote-to-cash stack – the collection of commonly-used tooling including Sales CRM, CPQ, customer success, billing platforms, finance systems, and analytics databases – does not work well for usage-based pricing. 

Secondly, that this is a problem fundamentally rooted in data. The ‘missing something’ is data infrastructure that 1) captures usage data, 2) applies pricing to it (ie rating), and 3) makes the outputs available a strategic asset that can flow seamlessly throughout the stack. 

To solve a data problem, you need a data expert. And we were fortunate to cross paths at the right time with Rob Franolic, our Chief Data Scientist. 

Rob spent two decades at CLS, a leading financial institution providing settlement services in the FX market, most recently as the Chief Data Officer & Head of Quantitative Analytics. After leaving to try something new, Rob was drawn to our way of thinking. It helped that he agreed that UBP would become an increasingly important pricing approach for software. But more importantly, he appreciated our data-first mindset, and was also excited by the opportunities to apply data science to create groundbreaking analytics, for example around allocating shared costs algorithmically to identify per customer margins, or forecast usage outcomes. 

Together we forged a vision. m3ter would help companies ‘instrument’ their business by capturing usage data so it could support operational and analytics use cases, and integrating it effectively with existing tooling so it can flow throughout the quote-to-cash stack. We would also build advanced services that address key gaps in that stack, particularly around complex pricing configuration, cost allocation, forecasting, and price optimization.

It would also be a ‘developer-first’ service. Developers need granular, technical control of how usage data flows around the organisation, so m3ter would work as they would want it to. We would offer great UI experiences that abstract complexity for non-technical users too, but the developer comes first. 

Building the right team

It was important that our team understood the problem space and also how to build highly scalable systems. We were lucky that many of our colleagues from GameSparks and AWS were happy to jump onboard with us again, which allowed us to work at high velocity and quality from the outset. 

But equally important was effectively melding high quality data thinking with our software development. Rob cherry-picked some of his former team and we added further data engineering and data science muscle. But we also needed to establish the right ways of working. The industry has learned to address schisms between Dev and Ops; it’s now doing something similar with Dev and Data. In our case, we’ve created an organisational design that has Dev and Data working in small, semi-autonomous, multidisciplinary teams with responsibility for specific services, but guided by a clear overall product vision. A by-product is creating a motivating place to work – our people have agency and independence, and the information to enable that. We’re having fun.

What comes next?

It’s a thrilling time to be working in the usage-based pricing space, as more companies implement the strategy and look for support to make it effective. 

We’re happy to be in the vanguard of companies providing that support. If you’re ready to join us on our journey to simplify UBP through data, set up some time to talk to our team.