Decoding Service Levels: Rethinking SLO, SLE, SLA, and SLM

Language creates reality, and when in comes to the delivery capabilities of organization the language around service levels sometimes makes it hard to improve the reality.

The SLA (Service Level Agreement) has become a very loose Term.

Non-sensical sentences like “I expect an SLA of less than two weeks!” for example (when used to underline the fact that the customer wants their delivery within two weeks or less) are way too common and make it hard(er) to discuss capabilities in a helpful manner. At least when we take SLA to mean Service Level Agreement.

Right now, early 2023, not only the SLA, but also the SLE is quite popular - the Service Level Expectation. But again – this term can easily be misused and its definition depends quite a lot on context. This term has recently been taken up by people working with Scrum and Kanban and they definitely have their own interpretation.

Sometimes it is helpful to look at the original meanings of terms and try to use them in a way that is most helpful to the situations at hand.

Back to original meanings

Let’s look at what the terms actually (used to) mean and how they could all fit nicely together:

SLO - Service Level Offering

The speed and quality of service that is offered by someone (a person, a team, or an organization) to someone else.

SLE - Service Level Expectation

This term was commonly used mainly in RFPs (Request For Proposals) and in the context of contracts and offerings and describes which level of service would be expected from someone who bids on this RFP. E.g. “If you want to be our supplier for headlights, than we expect that we will have any headlight we order within 48 hours as long as we don’t order more than 200 pieces.” Today’s interpretation sometimes differs, as can be seen by numerous articles around SLEs and Kanban and Scrum

SLA - Service Level Agreement

This is the actual, mutual agreement between two parties that has been reached after discussing

• the needs and hopes of the client (the SLE in the original sense of the word) and
• the capabilities of the provider (the SLO)

Most of the time an SLA that has really been negotiated also takes into consideration what each party considers to be a fair and economically viable compensation for that level of service.

SLM - Service Level Measurement / Monitoring

To make sure that everything still works as the parties involved intended it is a good idea to measure the actual service level to be able to make adjustments as needed.

Why can this be helpful?

Once we return to aknowledging the different needs of the different parties involved, it becomes much easier to arrive at the most important letter of this whole three-letter-acronym (TLA) zoo: the A as in agreement!

When the SLO is left in the hands of the people providing the service they can measure their own capabilities and actually know what they can offer.

When it is clear, that the expectation that the outside world has, can not be defined from within the party providing the service, but only from the outside, then the actual clients can (and have to) define what they need.

And if all parties concerned know what they can do and what they need they will have a much time coming to an agreement.

till next time
  Michael Mahlberg

What’s the «Minimum» in MVP (Minumun Viable Product) anyways?

“There can only be one!” (Or not?)

At least one of my friends gets “all highlander” on people who try to talk about having defined the MVPs (plural) for the product strategy and makes a very strong point of the fact that there can only be one (predefined) minimum viable product.

But is that really true? Or is it prudent to say “we’ve defined a couple of MVPs?” Does it make sense to talk about the amount of users who actively “use our MVP?” Or is an MVP a thing that does not really provide any user functionality?

Well – as I like to point out: Context is King. Always. And we have to accept reality as it is. In that vain, I think we have to recognize that people are using all the notions above.

From what I’ve learned over the last couple of years, at least two fundamentally different ideas behind the term MVP are widely spread and of course we also have to take semantic diffusion into account.

The MVP in the world of Lean Startup (2008)

With Eric Ries seminal work on The Lean Startup and the adoption of the whole lean startup approach, the term MVP gained real popularity.

Steve Blank, “An MVP is not a Cheaper Product, It’s about Smart Learning” “MVP is whatever you could build to learn the most at a certain time” in this interview at Startup Istanbul

According to Alex Osterwalder’s ideas for example, an MVP is “A model of a value proposition designed specifically to validate or invalidate one or more hypotheses” – at least in the context of value proposition design so I would argue, that there is some merit to this position.

The MVP in the world of product development (2001)

Way before Lean Startup, in 2001, Frank Robinson published a definition of the term MVP that is much closer to the concept I have most often heard associated with the term by people who have not been exposed to the ideas of Eric Ries :

The smallest product that will actually be sellable.

The problem with this outlook is of course, that the risk-issues Steve Blank and Eric Ries point out in their work are not at all addressed by this approach.

For those interested: the original wording from Robinson was > “ The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.”

For a more in-depth discussion of the topic I recommend reading through product board’s article about MVP and through the product schools’s comparision between MVP and prototype

Given this point of view, I’m inclined to argue that there is value in this position as well.

Other terms that might help

In the 2004 book software by numbers Jane Clelans-Huag and Mark Denne introduced the term minimum marketable feature (MMF) that nicely describes what is often meant when people talk about MVPs:

A chunk of functionality that can be sold together and makes sense for a potential customer to buy (Paraphrased by me)

till next time
  Michael Mahlberg