mvp service level objectives

Apply “Service level objectives” to product requirements to get an MVP. SLOs help to decide the level of service that a product will provide to a customer. SLOs are often used to define or describe the error budget of a service in the Site Reliability Engineering world.

Google SRE book “service level” definitions.

We can apply SLOs to product requirements, to build define an MVP.

Let’s follow a concrete example:

• We want to add comments to a wiki product.

I will leave out many of the details, so that we can focus on the reasoning behind the MVP.

We’ve worked out with one of our PMs that we want each comment to consist of:

1
2
3
4

{
  "text": "There's a typo in the article title, please review",
  "author": "some-id"
}

We decide to build the smallest and lightest weight verison of commentst that we can, this is to validate our assumptions about what customer want from a comments system.

Our team cannot decide on one part of the design:

• If this feature is experimental, should we invest in building pagination.

Building in pagination would lead to a larger investment in build time, under the assumptions that comments will be well used, and pagination will have an effect on DB query and page load performance.

The choice becomes; build now, or later.

The biggest problem with building later is that it becomes hard to properly prioritise the product change of “adding pagination” at some later date. SLOs can help create forcing functions that allow us to better prioritise product decisions.

If we don’t add pagination, and we see that users love the comment functionality. We see users are adding more and more comments, and soon we see pages with comments taking longer and longer to load. At this point, it’s really hard to decide what is “too long”. If we were OK with the page taking 200ms to load, why is it now unacceptable for the page to take 201ms to load. (It’s just 1ms more!)

If we explicitly define the level of service (SLO) that we want to include in the MVP from the start, then the decisions about “should we extend the functionality” become significantly easier.

We can change the question from:

• Should we add pagination in the MVP comments API?

..to…

• How many comments will we support without pagination?

Imagine we set a hard limit of 200 comments on each wiki page. We can return 200 results from our API, and block users from adding more than 200 comments to any single wiki page.

This calls out the assumptions that we would have made were we to add pagination upfront:

1. Users will use comments
2. Users will add enough comments that pagination becomes a requirement

And informs the product decisions that we might want to make in the future:

1. Does having more than 200 comments provide enough value to offset the cost of building API pagination?

We move the “implicit” potential performance degradation, into “explict” service level offering of the MVP.

SLOs do not need to be only “limits on user functionality” but can be applied to all parts of an MVP. (which set of users, load time, etc)

The number 200 was chose semi-randomly, but we can use the size of the response payload and expected database performance to inform what “one page” of results would look like.