This is an adapted excerpt from the book.

Minimum Viable Design Team

As the First Designer In (FDI), you’re not just building a Minimum Viable Design Team, you are the Minimum Viable Design Team.

The Famous MVP

Let’s take a trip down Agile lane for a moment. The concept of a Minimum Viable Product (MVP) was made popular by the likes of Steve Blank and Eric Ries. And ever since its rise to popularity, there has been much ado about what, exactly, MVP means. There have been plenty of poor interpretations; the MVP has become somewhat notoriously hard to nail down. So let’s start by defining what it is not. An MVP is not:

The best you can build in the time you have Does that thing you have built also happen to be useful for your user as well? Because if not, it is not an MVP. It’s just half-baked.
A buggy first release The presence of bugs does not an MVP make. Is that thing you released so valuable to users that they’ll put up with the bugs just to get their hands on it? If not, it’s not an MVP. It’s just a sloppy release.

In other words, an MVP is not a poorly built version of what you ultimately want to get to. It is the first time you deliver value.

There’s a famous illustration by Henrik Kniberg from his 2016 blog post, Making Sense of MVP, where he compares a skateboard to a wheel in order to make the point that, if your ultimate goal is to deliver a car to your user (so that they can get around without walking), then your MVP had better be a skateboard, at the very least, and not just a wheel. It looks something like this:

This analogy is helpful to get the most basic point across: give people something they can use from the get-go, and don’t worry about making it perfect. Just get it done.

The MVP Level-Up

Mike Hickerson builds on this foundation to add some more nuance to the analogy. In his article, The Agile Bicycle: A Better Analogy for Software Development, he homes in on what is missing from the analogy of the skateboard, “[it’s] neither incremental nor iterative development; you can never build a car by starting with a skateboard, bicycle, or motorcycle.”

I’m particularly fond of Mike’s proposal for an alternate analogy using the history of the bicycle. Here’s why it works better in Mike’s words:

Each iteration of the bicycle is focused on solving the same basic problem: using human power to move faster and farther.
The bicycle’s development was truly incremental, adding new technologies at each stage but using the same essential paradigm...
The development was also iterative. Different versions of the bicycle were released to the public by competing manufacturers, allowing user feedback to inform the direction of development…

Let’s draw out that new analogy:

Doesn’t that feel far more natural?

If you’re currently thinking, “That’s nice, but what does any of this have to do with building a design team?” It matters because an FDI needs to build a Minimum Viable Design Team.

Getting To The Point: The Minimum Viable Design Team

A Minimum Viable Design Team is not a poorly executed version of what you ultimately want to get to. It is the first time design delivers value (sound familiar).

Though an FDI starts off as a solo practitioner, they also must still represent the entire design function. An FDI is not a portion of a designer (a wheel). They are not a disappointing stand-in for the real thing (a skateboard). They need to be a fully complete design organization, with the correct shape and all the core functions (the first bicycle). Over time, as the needs of the company evolve, so will the nuances of that design organization (the ten speed, or, for a more modern example, the electric bike).

In the example of the agile bicycle, the problem being solved is, and always remains:

"How can I move faster and farther than walking or running, while still using only my own power?"

For an FDI, the problem being solved is, and will always remain:

"How can I move the company forward faster than if there were no designer, while still using only the power of my own skills?"

Establishing the goals for the design team requires plotting a reasonable journey from first bike to super-jet-powered bike. The likely milestones along that path need to be called out, yes, but there also needs to be flexibility for iterations. Those iterations will be unique to every company. So define a Minimum Viable Design Team, then let it evolve along the way as Design finds more and different ways to support the company's growth.