<!-- Content Here -->

Where content meets technology

Oct 03, 2017

Lean Product Development with SLCs rather than MVPs

I honestly can't think of a better way to build products and services than the lean product development method. All of the work I have done over the last several years has followed the pattern of growing a customer base around a small simple product that evolves and matures in response to the needs of the users.

Our latest product, Lionbridge onDemand, has been a great success and yet it started out so small: we were testing whether we could build a business around a self service video translation site. We built the simplest app possible but left room for growth. We leveraged operational talent that Lionbridge already had and an entrepreneurial spirit that was not being satisfied. We tested different ways to drive customers to the site. We got just enough market response to see a path and keep moving forward. Since our first sale, we have been constantly learning, optimizing, and expanding. Now onDemand is a thriving business with a broad range of services. We translate all sorts of content (over 40 file types) into pretty much any language you can think of. We have a public API and integrations with several popular content management and commerce systems. But most importantly, we have happy customers who rely on the service.

Whenever I want to build a new product, or even add a new feature to an existing product, my plan is to start with an MVP (minimum viable product) and iterate from there. But this article, "I hate MVPs. So do your customers. Make it SLC instead" by Jason Cohen, gave me pause. SLC stands for "Simple, Lovable, and Complete" and, after reading the article, I realize that SLCs are the recipe for success in lean product development; not MVPs.

Here is the difference. An MVP is (in a pure sense) the flimsiest thing you can build to answer a question about a potential market. The emphasis is more on the "M" (minimum) than the "V" (viability) and most interpret that balance as a semi functional prototype. This kind of MVP is frustrating to customers because it doesn't solve their problem in a helpful way. It focuses on validating that the problem exists and that there is value in solving it. MVPs are selfish because they prioritize research over actual customer benefit.

If you really want to learn about customer need, and build good relationships at the same time, you should take one customer problem and solve it well. Build an SLC. I know that the line is blurry here. An MVP could be an SLC if you make lovability a requirement for viability. But often you hear bad solutions as being excused or justified as "just an MVP."

The first iteration of Lionbridge onDemand did what was needed for a successful, gratifying transaction. In particular:

  • The customer could upload very large files. This is necessary because video files are big.
  • The project was automatically quoted so the customer didn't have to wait.
  • The customer could connect with an online sales agent through chat. This turned out to be a critical feature because we learned so much from our customers during these interactions.
  • The customer could pay for the service using a credit card so he/she got the experience of a seamless, self-service transaction.
  • The operations team was prepared to produce a high quality deliverable in a reasonable timeframe. The customer's need was satisfied.
While we launched the first iteration of Lionbridge onDemand quickly (less than 2 months from concept to first sale) we took the time to get those pieces right. That was a little over 4 years ago and our first customer continues to do business with us.

We are constantly adding new features to Lionbridge onDemand and every time we do, we treat it as an MVP SLC. We don't launch the feature unless it makes the user's experience a little better by solving a problem (however small) in a complete and satisfactory way.