How to Lead as a Founder

In the early stages of building a company, it feels like you’re being pulled in a thousand directions. It makes sense why so many founders get caught up in trying to do everything.

Everything feels urgent and important, but that’s simply not true.

You might feel the need to:

But that’s not how startups get built. The reality is messy, fast-moving, and oftentimes filled with mistakes and failure.

Fail fast and fail forward is the mantra of many, and here’s why.

As Y Combinator puts it, the best way to figure out what to build is to build something now and put it in front of real users.

Action provides clarity.

We’ll dive into two priorities from here that are really important for early stage startups. The first is loving your customers and the second is building the MVP.

The greatest short term and long term priority in business is to do things that show that you genuinely care about your customers.

It’s also a huge advantage in the early stages. Bigger companies simply can’t treat their customers with the same care and attention that you can early on. And doing that bleeds into company culture long term. I can’t think of a more important thing to prioritize.

Customers want to feel cared for, that their voice matters, and that you’re mindful of them and their needs.

Replace this:

“Thank you for submitting a ticket. A team member will respond within 3-5 business days.”

With this:

“Hey, I saw your issue come through. I’m the founder—just fixed it and pushed an update. Thanks for using us!”

The second version earns trust. The first gets archived.

The first version of your product, after the prototype, is the MVP, and that’s the first thing that an early stage founder should focus on.

I go into the technical side of this more in depth on the Software Developer Priorities guide.

Here’s the thing, your MVP will not be perfect, and it shouldn’t be.

Your earliest users aren’t looking for a perfect product, they’re looking for a solution to a painful problem. These are people who need a solution and need it asap.

If your customers believe that you’re genuinely trying to solve something that matters to them, they’ll be willing to tolerate bugs, unpolished design, and missing features.

You’re not trying to make a product that is going to be adopted by the mainstream customer right away.

It's not a test of how pretty your UI is. It's not a soft launch. It's not a demo video. And it's not a beta that secretly took you a year to build.

An MVP is not polished, it’s not infinitely scaleable or developed to the greatest level of efficiency.

If it’s going to take you a year to build the MVP, it’s probably not an MVP.

A Minimally Viable Product is the

simplest version of your product

that lets you test whether you're solving a real problem.

An MVP should do three things:

It’s the fastest path to user feedback and product-market fit. Without it, you're flying blind.

Early on, the goal is to solve one problem, not 10.

It’s easy to look at existing software and see all the features they have and think that your product needs to be at the same level. No successful startup magically knew what their customers wanted before launching their product into their customer’s hands.

This also means that you’re likely going to appeal to a narrow audience of people with the MVP. If you try to serve everyone, no one will be served.

When you spread yourself too thin with feature sets and solutions, you delay feedback from real users. With one clear problem, it’s easier to get feedback and iterate with less technical debt.

Here’s how to approach building your MVP the right way:

1. Give yourself a short, hard deadline.

Decide on a two- to four-week window to ship something. The shorter the better. Pressure forces clarity.

2. Write out your MVP spec.

List all features you

think

are essential. Then…

3. Cut your spec in half.

Ask yourself: “Does the first user absolutely need this to test the value of the product?” If not, cut it.

4. Focus on learning, not impressing.

The goal is not to impress users with a perfect product. It’s to learn what they need and how far your current solution gets them.

5. Fall in love with the problem, not the product.

Your MVP will change. Maybe even drastically. Don’t get attached to the version you launch. Get attached to the customers and the insights they give you.

Now, let’s wrap up all these ideas with some continued application from my personal story.

When I first started building the software, I made a prototype using Webflow, Whalesync, and Notion as the database.

There was no user authentication, customization was limited to Notion’s functionality and Webflow’s CMS. Basically, things were held together with some pretty basic tech that couldn’t scale.

The only feature it had was the ability to make a post that looked like it was on Instagram and a basic request feedback feature which was a simple form.

It could only handle one client, Connor’s Aebly Studio. The product was kinda clunky. But here’s the thing, it worked! And it worked because it solved an urgent and important problem for their business.

This prototype gave me a clear vision for an MVP that I then built using Webflow, Wized and Xano.