MVP for Agencies and Clients

Building Client Projects with a Minimum Viable Product (MVP) Approach

By Wednesday June 24th, 2015

The MVP model works great for startups, but does it work in an agency/client setting?

MVP stands for Minimum Viable Product, and it’s a method for building a product that focuses on ongoing releases and iterations. The idea is that you deliver the minimum features and functionality that is required to get feedback from real users to guide the next phase of the project.

People and companies take this concept to different extremes, but that’s the gist of it.

There can be no dead ends, errors or lorum ipsum.

Why MVP is Awesome for Startups

For a new company with a new idea, MVP is an amazing way to build that idea and test the market, because it reduces the amount of time spent on speculation and features that may not be necessary.

It also helps to prioritize features and to focus a product’s core value.

Startups use the MVP model to get to market quickly, and they often end up with a more relevant product because it’s shaped by user feedback.

Is MVP Awesome for Client Projects?

Contracted work for clients, however, may not be as obvious a fit. Is the MVP approach awesome when you ultimately need to answer to a client? Is it even possible?

The answer is yes. MVP for client work is both awesome and possible, but it’s much harder to successfully build with an MVP approach for clients than it is for startups who are building for themselves.

At Brolik, we’ve run more than a few client projects with an MVP (or MVP/traditional hybrid) approach, and we’ve learned a lot in the process.

Here are a few tips for other agencies who want to start tackling client projects on an ongoing basis using the MVP model.

How to Successfully Navigate an MVP Approach for a Client Project


This is the most important part of MVP for client projects.

Education, education, education.

I can’t overstate that.

Educate clients on what MVP is, what it means for their project specifically, and about the many pitfalls the project may face. Make sure to push the benefits as well, but fight the urge to brush over the uncomfortable or risky parts of the MVP process.

Honesty will pay off, so mention that the process will be challenging at times (it will be).

In addition, educate all or as many of the stakeholders possible. If you only convince the marketing director to go MVP, and they don’t convince their CEO, you as the agency will ultimately be responsible if the project goes sour because the CEO is confused on timeline, deliverables, features, or anything else.


Right along with education, constant communication is a key to a successful MVP build. In fact, I’d recommend over-communicating when dealing with MVP.

MVP, more than traditional methods, requires weekly calls. This isn’t because the project is more complex or confusing. It’s because the project will move really fast, and part of the MVP approach is the constant prioritization of ideas, goals and features.

Keep your normal project milestones if you want, but both parties need to be in weekly-ish communication, or there will be incorrect expectations at the larger milestones.

Polish Every Presentation

This one is true for the end user as well. Anything “released” (whether to the client or to the public) needs to feel finished. There can be no dead ends, errors or lorum ipsum. Sell trust and confidence in the product by polishing the shit out of all the features that do exist.

During an MVP build, inexperienced clients sit right on the edge of buying in and giving up. If you don’t polish, clients will quickly give into their fears and decide the whole MVP approach doesn’t work because they need a finished-feeling product. After all, they’ve got someone above them to answer to, and that person doesn’t care about the approach. They just want a finished product!

This tweet/graphic illustrates this point well.

Keep Everyone’s Eye on the Prize

Every MVP approach is centered around a few overarching goals that should be referenced when making decisions.

A client MVP project will be much more open and free form than a traditional project (by design), so referencing and reminding the client of those main project goals becomes more important than it is normally.

This is also a good way to resolve questions or disputes. Frame it against those initial goals, and let the facts speak for themselves.

Benefits of Client Project MVP

If you can heed those warnings and are interested in building client projects this way, you’ll find there are a lot of benefits.


A hidden agency benefit of the MVP approach comes with the shift in mindset that it encourages.

If the client gets used to releasing and iterating, what’s to stop them when the final contracted milestone is hit? Sign them on for an entire year, as a monthly retainer, where both sides can analyze and optimize the product ongoing.

If you’re not doing this already, your cashflow and projections will become a lot more manageable when you can count on contracted, monthly income.

User-Dictated Features

Another benefit is the reduced friction between the agency and the client over features and functionality.

Both parties know that new features are ultimately dictated by testing and user feedback, so agencies don’t have to defend their design decisions, and clients don’t have to defend their business decisions. It’s all based on the users.

In the end, the product is better, because it’s based on data instead of assumptions.

Scoping Projects Gets Easier (Ironically)

Sometimes, a project is so large and there are so many unknowns that the only way to estimate pricing is to over-quote or over-research. Both are problematic.

MVP is a great way to get a large project started. Both the agency and the client are secretly scared of locking in features and functionality in the contract phase, but until recently, no one thought we could do otherwise.

At Brolik, we prefer to outline a general set of features and functionality in the contract phase and then run the project from a “Features and Functionality” document that puts features “above the line” or “below the line.”

This requires a bit of trust, but as the project evolves and feature requests are added or changed, the Features and Functionality doc gets arranged accordingly. If the client wants a feature that’s large and “out of scope,” we don’t have to say no. We just have to figure out what we can move below the line in order to make room above the line.

° ° °

The MVP method is an excellent way to handle the evolution of ideas that happens during normal, healthy product development, but again, it only works if you address the challenges and avoid the pitfalls.

Remember that MVP represents change. It’s a change in the way thousands of people and businesses work and think. It’s a change in deliverables. It’s a change in mindset. It’s a speed change, and it’s a change in the way we measure success (and failure).

And as we all know, everyone hates change.

So be smart about MVP for clients. Be a teacher first and an agency second. Be a passionate advocate. Be confident (even if you’re unsure about a detail), and use your experience and expertise to make good decisions. In the end, be the future, because there really is no better way to build a product than a minimum viable approach.

We advocates just need to wait for everyone to catch up and realize that.

Like what you just read?

Sign up for updates whenever we post a new article. No spam. Promise.

About the Author

Drew Thomas is the CTO and co-founder of Brolik. He oversees Brolik's technology projects, including Leverage, Brolik’s proprietary technology platform. Drew spends most of his free time on side projects and prefers to blend work and life into a balanced, enjoyable experience. He lives in Austin, TX.
Twitter: @drewbrolik
LinkedIn: Drew Thomas
Google+: Drew Thomas