Becoming a world-class product manager

Prior to AI, building the first version of your product was very expensive and time consuming. It could take anywhere from 1-6 months, if not longer, so you wanted to be very careful what you built so you don’t waste six months building the wrong thing.

With AI, time is no longer a problem. You could build a minimum viable product (MVP) in several hours to a couple days. This has created a phenomenon of people building maximally viable products, which is a whole other problem of its own. What I see over and over again with AI is people who build their base product in 30 minutes, then, after seeing how easy it was to build something so complicated, begin bolting on feature after feature after feature. The result is often wide and honestly pretty impressive, but is the quickest way to kill your product and business.

Firstly, many people get stuck in the perpetual feature loop because it is easy and comfortable, and it gives a false sense of progress. Rather than declaring a hard line for what constitutes a v1, many builders prefer to keep making their internal v1 more and more impressive, because adding new features feels really good. It gives you a sense of accomplishment and an accompanying dopamine rush, and you are tricked into feeling like you're making progress. The truth is, every feature you add that is extraneous to your core proposition, to the core thing that will convert customers, is you moving in the opposite direction of progress.

I assure you that this will happen to you, and it’s good you’re taking this course, because I want to stop this from happening to you dead in its tracks. Because here's what's going to happen. You're going to have a landing page. You'll have a website. And you'll have a product. You'll have all the ingredients. And you will have no customers. And you'll have no idea what to do next.

Slowly but surely you'll begin talking yourself out of your idea. “It’s no good anyway. What purpose does it really serve? It’s a piece of crap, who needs this? Maybe I better move on.”

It’s backwards but it’s true. Surrendering, giving up, feels great in the moment, because you're immediately resolving the tension that is nagging at you. But it’s a false resolution. Instead, everything you do should be designed in a way that makes giving up impossible. It’s why I keep saying work slowly.

And what I’m going to teach you now is to work horizontally, not vertically.

A software product or startup consists of many verticals that all must come together to create a symphony. You have the code, design, marketing, social media, customer service, automations, financials, analytics, and so on. Imagine each one of these as a vertical bar. The taller the bar, the better. However, you want to keep these bars balanced such that one doesn’t grow too tall out of proportion.

Most coders know this problem all too well. Because they’re really good at coding, they’ll spend 90% of their time on the code. And so their code vertical bar will be very tall. But everything else will pale in comparison. That right there is a failing business.

For every inch you grow in code, you want to grow in proportion in other areas, like marketing and social media. I promised in this course to teach you how to launch a business that makes money, and not just how to write code. It’s not something that can be done in a few days. It takes time, effort, and perseverance. But absolutely nothing is more worthwhile if you stick with it.

Let’s get back to the question at hand: what should you build? How do you know when it’s ready?

Let’s start with some principles. Firstly, build in the direction of what your customers will encounter in their first twenty minutes. You can build really impressive features that a customer might not encounter until their second week with the product, but those are useless features to build, because you haven’t yet even gotten a single customer to spend seconds with your app.

Ask yourself this: what is the set of features you think a newcomer will encounter in the first several minutes that will convince them to keep investing more time in your product?

That’s your v1. Simple as that.

For the record, if you can get a newcomer to spend twenty minutes in your product, understand that that would be an industry record. One study of 2.4 million ecommerce sessions found that people decide whether to stay or leave within the first ten to twenty seconds.¹ So it’s a total waste to build very deep features no one will ever see.

Now, deciding what actually goes in that twenty minutes is harder than it sounds, because every feature you thought of feels necessary when it’s your own idea. So you don’t have to do it alone. Describe your product to your agent and have it help you gain perspective:

Here's my app idea: [describe it in a paragraph, including who it's for].

List every feature this product would eventually need. Then cut that list down to only what a brand new user would encounter in their first twenty minutes.

The list it hands back is your v1, and it will probably feel too small to you. That's a good sign.

In a world where you can build anything, the question is not what you build, but what you don’t build. It’s in that negative where your product lives. Just like a camera allows anyone to take thousands of photos, what makes a professional photographer is the shots they don’t take (amongst other things of course).

Now to be quite honest, most of the difficult work will not be around building your features. It will be about building architectures that can support your features. Things like authentication, database models and architecture, and more. Not to worry however, as we’ll cover all that in this course.

The simpler you can start, the more likely you are to actually launch your product. If your product gets to be too complex, you will have less confidence in it, and you will play whack-a-mole with bug fixes such that you never have enough confidence to actually launch. And your project will decay into the project cemetery that all projects naturally gravitate to.

Trust me when I say that understanding these principles of discipline and simplicity will do more to get you towards a shipped product than anything I can teach you about code architecture or anything technical.

So before we continue, I want you to repeat these maxims to yourself:

1. I will not keep adding features because I’m not sure what else to do
2. I will work on all verticals and not just hyper-focus on adding new features
3. Absolutely nothing is more important than shipping a v1 of my product that may be embarrassingly simple, but is complete and stable.

Once you’ve internalized these principles, it’s time to move on to actually building your v1, the first iteration of which we will call the alpha. Once the alpha is polished after responding to user feedback, we call that the beta. And once the beta is smoothed out in response to user feedback, we call that the release candidate, or just generally, GA (general availability), production, or just launch.

These words are really about deciding who sees your product and when. Your alpha is for you and maybe a friend or two, and it should be very rough. If you're feeling ready and confident you've waited too long. Your beta then goes out to the first handful of real users from your wait list, and you'll use their feedback to turn it into something worth launching. The mistake I see people make most often is people treating their alpha like a release candidate, polishing it in private for months because they haven't learned to accept that the alpha should be extremely rough, and that it should be seen and used by people as early as possible.