Conditioning Your Clients to Think in MVPs
I’m a fan of people with big ideas and the enthusiasm to back them up. Unlike some of my friends and business partners, I’m not known to have the wildest imagination. I was never the most creative kid. I tend to think in more logical and structured ways.
So when you put me in a room with a Big Ideas Person, I’m infected with their enthusiasm, but my mind instantly starts thinking about practicalities. For example, how will the database store the information? What settings and functions would a user need on a given page? How could those be laid out in the most usable way? And, most importantly, which pieces are an essential part of the minimum viable product (MVP)—and which can be pared away?
I’m sure we’ve all had that client, the Big Ideas Person, who begins their project by listing off all the incredible things their product or service is going to be able to do, and then continually adds elements to designs and functional prototypes. As time goes on, the project grows like the Frankenstein monster until it gets to a point where you have to completely re-evaluate not only your Statement of Work but also how the whole application will function.
Of course I love the enthusiasm, and those types of clients are great fun to work with. But to build applications quickly and effectively we have to focus on the MVP. So how do you get your clients to think in MVPs?
Make it a part of their vocabulary
The term MVP comes from the Lean movement in business, which focuses on getting the most out of as little as possible. Throughout our process we continually bring up the term MVP to remind the client when we think they’re getting ahead of themselves. By conditioning our clients early in the process to think in terms of the MVP (e.g. from our first conversations with them), we create a sort of Pavlovian response. (“MVP means cut back. MVP means simplify.”)
By bringing MVPs into our process before we sign paperwork or design pixels, our clients know that we’re not just building their product blindly. MVPs encourage us to think efficiently and creatively about the project, and be a part of its success.
One way to explain it is to say that we do it to keep our clients around—we know our process works and we know that if they work with us through our process not only will their product be better for it, but ultimately they’ll return and continue to work with us as their product continues to succeed.
Defining all of that early makes bringing it up throughout the process later a lot easier. It’s not that we want to cut corners or make our jobs easier—we just want to get the idea out there sooner. Sometimes this means designing only 5 of the 50 pages we’ve wireframed because we don’t want to waste time mocking up pages that re-use styles from previous pages; other times it just means scaling down complex functionality if it’s not needed so that we can focus on building the core of the application first. (“MVP means one step at a time.”)
Set client expectations early, and make sure that they know you’re not afraid to tell them when they’re exceeding their MVP.
Don’t be afraid to push back!
What I’ve found is that the Big Ideas Person needs to be pushed back from time to time. Challenge them! Disagree with them! Tell them (gasp!) No, with a capital N.
Sometimes you’ll be completely wrong and the client will show you that in their market tests with potential users they actually requested things a certain way—but at that point at least the cards are on the table. This discussion yields reasons for decisions, which lead to better decisions down the road.
“Whoever best describes the problem, is the one most likely to solve it.” – Dan Roam
There’s always a learning curve when you bring new clients into your process, and in the case of the Big Ideas person this means pushing back. But challenging your clients doesn’t mean you have license to be a jerk. Find a way to have a level, intelligent discussion, and keep personal feelings out of it. Our clients hire us for our design skills, but also for our experience doing this sort of thing (whether it’s UI design, landing page conversion, incorporating feedback, adding new features, etc.)
Part of our job is teaching our clients about our process, which is tailored to getting an MVP out into the wild with minimum budget and in record time. We have to explain to them how adding too much too soon is counter-productive, and that if we stay too focused on a “finished” product we won’t be paying attention to the important foundational elements. We have to encourage them to listen to the feedback of their actual users instead of chasing the vision that exists in their creative mind.
As anyone who has ever worked on web applications knows, once the user gives feedback the focus of a project shifts from “add new functionality” to “make the current functionality work better for the users.” Focusing on the MVP allows our clients to get feedback as early as possible, and see how their product fares in the real world, so they can focus their creative energies on realistic expectations.
Clients don’t always know what they need
Some people may think of this as a paradigm shift: the design studio telling their clients what to do.
You may think this sounds nuts. A lot of studios are afraid to tell their clients what to do. “They’ll never go for it,” is the standard objection.
But in most cases our clients grab onto this suggestion. They see the value in the lean process that we have tailored to work for us. With our direction, they start to think about what functionality is necessary, what can be cut, what we can do to get the product out faster (and feedback returned sooner), how we can iterate in phases, etc. Our discussions shift from wants to needs, and every element is scrutinized to see if it makes the cut.
Now we’re making progress! The foundations are getting built, the process is efficient and focused, and all it took was a little push.
Thinking in MVPs reduces the chance of feature bloat
I’ve consistently stuck up for Facebook over the last few years as a perfect example of an MVP that has grown over time. The first version of Facebook was simple, both in terms of design and functionality. Over time, the team at Facebook added new features, as well as updated the design to make it more robust and complex. These changes, while occasionally opposed by some users, were based on feedback given by users that created a need for the application to change.
I’m not arguing the point of whether or not Facebook is a prime example of feature overload (I think it is), but overall they created something small first, and let their users (and sometimes the people putting money in their pockets) decide what to add to it, which is exactly how an application in the real world gets built. From the Facebook example, you see how the Lean MVP approach works in the wild. It’s a good example to use, too, because almost every client that wants to make a web application is familiar with the evolution of Facebook.
The more focus we put on the lean MVP process, the easier it is to ensure that the application we are building puts the users’ experiences at the forefront.
“We had more complex initial mockups, but we pretty much erased almost everything and started over. Every feature was questioned, and we basically required a unanimous vote for any feature to make it in the app.” – Phil Ryu
What else can we learn from MVPs?
Ultimately, the lessons we learn by focusing on MVPs can be applied to every project we take on in our lives, whether it is for work or for personal satisfaction. If we think in terms of small simple steps we’ll all build better things.
Whether it’s breaking down the little things you need to do into lists (we do it all the time with grocery lists, budgets, and in our calendars), or big things like buying a house (do you have enough for a deposit, where do you want to move, what do you want in the area), thinking in simple and logical steps allow us to focus more on getting things done. It doesn’t mean you can’t be creative, it just means less thinking and more doing.
The Phuse’s goal in any project is for the project to be successful not only in it’s process and execution from our end but in our client’s execution as well. The success of the applications we build will come back to us just like good karma.
“The future will come by itself. Progress will not.” – Poul Henningsen