You will hear "MVP" every couple of sentences in the startup world.

But how do you know a product design is minimal and viable? The short answer: you don't. The truth is that before launching your product into the harsh reality of the market, there is no way to know that your product is viable. To know for sure, you need to test it.

But, it doesn't mean you are hopeless. Most people make an educated guess and hope for the best while saving some budget for after-launch adjustments. You can use these second and third models to find the behaviors required (not necessarily sufficient) for a viable product.

Before I discussed a maximum of this method: "users must get more value out of the product than the effort they put in." It's true about users interacting with what you build, but it's also true for every actor that has something to do with it. Starting with you (and your investors) looking for all of this will eventually be worth the trouble.

A user uses a product, but it is not necessarily the one who pays for it or decides to use it. For example, when a parent buys a child, a toy is paying and making the toy available to play, a way of deciding usage.

This dissociation is quite common, especially on business-to-business (B2B) products. A physician does not decide what health electronic records software they are using. The hospital board probably made the final decision to buy it out of the recommendation and technical specifications made by others. Then some supervisor notified the physician to use it from now on as part of his daily life. Does that mean we shouldn't mind what physicians think? No.

Whenever I ask the question, "why would a physician use this product?" I often hear back "because the hospital makes them." That's a lousy answer. You see, the doctor may not have a choice but can voice discontent to the decision-makers and them in turn, change their view on how good the software is.

A good product provides value to everyone involved.

Products have at least these three roles that make them viable, someone that pays, one that decides to use it, and someone that uses it. Sometimes this is one person, sometimes it is three.

The Model

To construct this model, list in a row all the actors you have identified. I suggest adding a small user icon 👤 next to each of your actors to make them easier to identify throughout your design documentation. Think of everyone that is involved with the product, directly and indirectly. At a bare minimum, this list should include a user.

On top, in another row, list all the roles your product requires. This list should contain "Pays," "Decides usage," and "Uses" but might include other items such as "Recommends." Remember, an actor can fulfill several roles, and more than one actor can play a role.

Finally, join with a line the actors with their roles. If any actor fulfills the role indirectly, you may use a dotted line to represent this. Once finished, take a look at your model, check that some actor covers every role, and try to find ways to minimize the roles or actors required.

Your next mission is to understand each actor's motivation to fulfill this role. We will explore this in the third model.