Why MVP is the Best Way to Develop Product | AppsFlyer
4 Min. Read

Why MVP is the Best Way to Develop Product

Avatar Adi Shacham-Shavit Jun 28, 2015

Minimum Viable Product (MVP) from Wikipedia:

“A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.”

For a start-up, using MVP is a matter of “life or death.” You can run out of money until you develop the “perfect” product. It’s important to understand exactly what the most cost effective features are, in order to be able to go to the market at the right point. The decision of what to develop or what not to develop must be part of the daily routine of a successful startup.

It’s usually when a company is growing, be it manpower, revenue or clients, when it becomes more difficult to understand this balance point. It’s not easy deciding when to release the product. The “good enough” point varies as there are always different opinions, growing needs from different clients and new markets impacting your decision.

At AppsFlyer, it’s clear what the strategic business goal and what the tactical goals are. A new feature in the system can come from clients’ requests, from strategic partners’ opportunities, from understanding where the market is going to and more. Every such feature is considered carefully in the context of whether or not it can contribute to the tactical or strategic goals in any way. If not, we put it aside until it resurfaces. If yes, it’s the product manager’s challenge to understand what is the minimum viable functionality.

I heard several times in the past that MVP might be difficult as an R&D methodology. Well, it’s not an R&D methodology — it’s the way we work! We all work very closely together. R&D, product managers and the business team outline the requirements and get feedback from clients in order to understand where to go next. Getting the right feedback from the right clients is crucial to make the right selection. Not having the right clients in the early beta of the product might cause the business to go in the wrong direction. The business team should be able to prioritize very accurately and R&D should be able to deliver quickly.

[Tweet “Getting the right feedback from the right clients is crucial to make the right selection “]

Fast delivery is a challenge for R&D. How can you deliver fast while maintaining the quality of the product and the system’s stability? Our daily workflow is comprised of tasks that are constantly reprioritized, mitigating the need to wait for the next release for another important feature. We use continuous deployment to deliver features, so there is no need to wait for the next maintenance window, and we work closely with the business to make sure every developer completely understands the usage of the system in order to make the right design decisions.

Case in Point

Let’s take a simple example and look at the process around our “TV attribution” feature:

Matan: TV attribution is an opportunity. We need to figure out how we can fit it into our platform

Adi: How should we attribute TV campaigns? Can we enhance one of our current services?

Matan: What if we’ll use “Service A” and correlate a TV ad with a click coming from a regular media source?

Adi: That’s doable. Let’s start with implementing the backend logic, and once we have a client that wants to use this feature, we will manually configure it for them.

That can be in production by the end of the week.

Matan: Cool, let’s do this. Once we have a few clients using it we’ll start working on the configuration UI. We can also start with an internal UI for the AppsFlyer Biz team.

Adi: Do you need batch uploading? Do you need a timestamp for campaigns? What other fields do you need?

Matan: We need fields A, B, C and D for manual configuration through the UI. We might need to update later on, depending on the clients’ feedback

Adi: A simple UI, for internal use should take no more than a day or two.


A few clients and a thousands of TV campaigns later…

Adi: It is about time to scale the system and create the UI we were talking about. Let’s also use this opportunity to create a batch upload.

Matan: Clients using this feature are asking for 2 additional fields. Let’s update the TV campaign format we can handle to include them. We have a few more big clients launching a TV campaign next week.

The Result

The result is a TV campaign attribution feature which is in use by many clients and handled over 10K campaigns in the first month since it was released. It was also built taking into account feedback from multiple clients that used it to determine which campaigns worked best for them.

The alternative of defining and designing the complete feature requirements for this feature without market validation and introducing it to our clients only afterwards would have resulted in a different feature which wouldn’t meet the clients’ needs and take us 1-2 months more than it took.

To Recap

MVP can be your business competitive advantage by delivering faster and working closer to the market. It can also be a major differentiator in the R&D development work— it is less common for developers to have a short feedback loop, that is essentially hours rather than days or weeks. It is not easy to go to the market with minimal viable product, and if your business can learn how to do it, this can make the R&D work more accurate. I really recommend you to try. Start with a new initiative, with a small cross functional team and continue from there.


Matan Tessler, our Product Manager was a special guest editor of this post.