The MVP Mindset

One of the downfalls of leading (or being a member of) a high performing team is that the bars get higher and higher. And I do mean bars, plural — there are two. The one set for you by your organization, and the one you set for yourselves. If you’re a busy team, or if you have lots of competing priorities, keeping your own standards high can sometimes slow you down.

Having high standards for yourself or your team isn’t intrinsically a bad thing. I’d argue that you can’t be truly high performing without high standards. But past a certain point, you should consider whether it’s slowing you down too much. Maybe you have plenty of time and capacity on the team to quickly create something amazing, but it’s more likely you don’t.

This is something my team and I struggled with. As our workload increased, I was trying to get better at noticing when we’d set the bar too high, particularly for training materials and documentation. My framing for this was “done is better than perfect.” That was helping around the edges, because it gave us a way to think about whether something was at the point where tweaks and changes weren’t doing much to improve the end product.

But something was missing. “Done is better than perfect” doesn’t help you think about quality; the focus is on completion. We still have high standards, but we need to adapt them for reality. It also didn’t resonate for me for a project larger than a single handout or blog post.

Then we encountered the Agile concept of the Minimum Viable Product (MVP). This is the simplest product you can get away with — something that will meet the core requirements and be good enough to release. Once it’s in your users’ hands, you can start getting feedback from them and using that to inform your next steps. There are probably some features still on your list, but now you have space to incorporate new ones and do some informed prioritization. Plus, you can more easily make changes to what you’ve just built and validate your assumptions about what your users will and will not actually use earlier in the process.

Eventually we started thinking about our other work in this way. It can feel odd to take this approach with customer-facing stuff, especially when it’s something that you don’t typically see labeled as a beta, like training resources or documentation. One way to think about an MVP in that scenario is by asking a question — is this ready for users? “Ready” can mean a lot of things, but it isn’t as final as “done.” Something can be ready before it’s done. And if you don’t have anything at all, even an imperfect version 1.0 is an improvement to your users.

This approach also supports a mindset shift. Instead of putting your project out there when it’s finished, you go into it knowing you’re going to continue to work on it after you release or distribute. And that you’ll be incorporating user feedback. That could be data from usage patterns, feedback from a few ad hoc conversations, or an analysis developed from a more formal approach.

This can be a great tool for engaging customers. People love to share their opinions, and pulling back the curtain on something like training materials or documentation is a low-stakes way for the organization to give customers an inside look at how things are done. You get the feedback you need, and you’ve helped to build the organization’s relationship with that customer. The customer gets to help you with something that will help other users, and it’ll be a much faster turnaround to when they can see their ideas incorporated. (Because you will follow up and share the next version, right? Right.)

Working to “ready” instead of “done” can feel a little awkward when you’re struggling with some aspect of whatever you’re creating. Take this post. I’ve been working on these last couple of paragraphs for a couple of days now. Is it done? No, I think I need a better conclusion. But is it ready? Absolutely.