The Most Elegant Product Framework You’ve Never Heard Of

04 Dec 2024

Ever thought you needed another framework for “doing product”? Yeah, me neither.

Agile. Lean. Jobs to be done. Customer journey mapping. It’s all a bit much.

That said, I recently came upon what may be the most elegant and effective way to build successful products from scratch.

It’s called “the 5Ps” and heavily inspired (read: stolen) from The First Round 4Ps and it goes like this:

People => Problem => Promise => Process => Product

People Come First

When it comes to building a commercially successful product, very smart people–like Marc Andreessen (inventor of the web browser and famously successful venture capitalist)–say that choosing the right market is probably the most important thing.

If you launch a good (or even great) product in a bad market, it will likely not succeed. But if you launch an OK (or even bad) product in a great market, it will likely still succeed.

How do we ensure we’re in a good market? Realize that markets are groups of people with a common set of problems. We need to find those people, and we need to understand their problems.

Problems Second

When talking to people that might make a market, we should focus on discovering and understanding their problems rather than biasing towards our beliefs or preferences (see Talking to Humans).

It’s pretty common for people to not really care about problems we think they should. This can often be very humbling!

Also, some problems are more important than others. We want to find problems people are willing to pay to have solved, or ideally have already tried to pay to have solved.

We should only move on until we identify and deeply understand a common set of problems a group of people are willing to pay to have solved. That’s our market.

Then Promise and Process

After we find a common set of problems, we want to devise a solution in the form of a “promise.” According to First Round:

It’s easy to confuse this for your actual product, but the promise is how you communicate the benefit your product will deliver.

Ideally, this benefit should be communicated in concrete terms. It will save customers X amount of time or $X in exchange for $Y.

This promise should also be unique, in the sense that it’s differentiated relative to other offerings on the market. People need a unique reason to choose our solution.

Alongside this promise, we also need a sense of how to execute on this promise. Ideally, this solution is a well-defined process (maybe manual or janky at first) we can use to execute on our promise. We offer a person X in exchange for $Y and execute a series of well-defined steps to deliver on that.

Before moving on, it would also behoove us to follow “The Algorithm” when developing this process. Question every requirement, remove as many as possible before simplifying and optimizing.

Product Last

Only after going through all of the above should we automate the process that executes on our promise. This will reduce costs/ increase margin by making value delivery (and ultimately revenue) independent of labor and time.

We only do this when we need to scale. The purpose of software is to make valuable processes infinitely scalable.

Important note: Most product builders start here b/c it’s the most fun. That’s a massive mistake.

Don’t start with automating. Start with finding and talking to people.