As you embark on your product journey, it’s important to remember that you’re supposed to create an experience that provides value and captivates an audience. Your product, in essence, is a show.

You’re building a product, but you’re also a screenwriter. You are directing the action from a user landing on a page to their first experiences taken on your product. You are scripting the entire process and designing it around a desired outcome. Every small iteration you make serves that outcome; if those outcomes aren't clear, you have a more significant problem. When a user leverages your product differently than expected, you learn from the critics, adjust your script, and ship the next part of the series.

One concept from screenwriting that should also be applied to building products is the “But and Therefore” rule. 

Essentially, the rule revolves around replacing the words “and then” any time they're found in your script with “but” and “therefore” to build tension and eventually reach a logical conclusion. This tension refers to providing the reason why actions are being taken in the first place. Using “and then” creates a dull structure based solely on the writer’s desire to list actions they’re excited about. However, to a reader, it’s dreadful because it feels like you’re just being thrown around a story in which you have zero vested interest. 

Let’s break it down a little bit and give a traditional example in the context of a quick script:

Here, we have a character, Jim, waking up, speaking to a character named Bob, and going home – all without any reason linking the events. It’s dull, and although it may seem like an obvious pitfall to avoid when writing, it’s pretty straightforward a trap to fall into.

This same style also applies to building products. It's very easy (actually quite fun) to list a set of user actions without anything stringing them together. You want your users to take actions on a product or platform—that's a given, but what leads them to those actions is the most crucial part. The difficulty comes from figuring out the user flow and actions that are compelling enough to lead them toward that desired outcome.

Let’s apply the “and then” framing to an MVP of a social product that optimizes for user interactions: 

As you can see, we have a set of desired actions but nothing as the catalyst to move the user across any of them. We want users to log in, update their profile, post, and check the news, but it’s disjointed and feels like a wishlist. Instead, it should feel like actions are continually supported and reinforced by other actions, and using the product becomes an engaging activity.

Now, let’s take it a step further and convert our "and then" scenarios to a “but and therefore” framing. Our original script with Jim looks a bit different because we now know the causes and events that took place which drive the story:

As you can see, the missing context drove the entire plot to begin with, much like contextual guidance is required to drive a user’s first interactions forward. If you start to design a product with an “and then” mentality, you won’t be driving users to where they need to be on your product, and you won’t understand what kind of interactions you need to enforce to make things sticky.

It would be best to optimize for outcomes and the hooks that lead to those outcomes. Let's take our original "and then" MVP app example and apply this new framework to it:

Now, we have drivers throughout the user journey that lead us to our following action. There is now a clearer reason for a user to edit a profile or engage with content. An “and then” mindset prioritizes scattered features over a cohesive experience. Start replacing every “and then” with “but” and “therefore" in your product journey.    

If a product is a show, your MVP is the pilot pitch.