If you work in or around some kind of software development, you’ve probably heard “MVP” sputtered in passing conversation, or seen it scribbled in a comment of a Google Doc. “MVP” is an acronym for “Minimum Viable Product.” The definition of an MVP is a loaded one, and changes slightly from Product Person™ to Product Person™. One popular definition is, “What can we build that will give us the most validation?” The school of thought I personally subscribe to (and will be using for the duration of this article) describes an MVP as “the smallest solution you build that will bring the most value to your customers.” At first, all of this probably sounds straightforward enough, but there’s deceivingly a lot to unpack here; in my experience it’s never just “what’s the smallest solution.” In one of my favorite articles about MVPs, they say, “Starting with a solution is like building a key without a door” (9). It’s easy to fall into a cycle of Build/Measure/Learn (as the first definition I mentioned often