The Skills That Made You Successful in Corporate Are Killing Your MVP

Welcome back to NoteLoft Newsletter - the shortcut for founders who want to go from MVP to scale. Every week (ish - I’m working on it), my goal is to share what actually works when building software, so you can spend more time on deals, growth, and going to Pilates.

If you need help taking your product from MVP to scale, get in touch! We’ve grown our tech team, and we can’t wait to help you.

Let’s get into it!

I always hated working corporate.

The unnecessary meetings, the gossip, the backstabbing for a 2% raise. The endless debates about things that didn’t move the needle forward. Managers who play favorites, colleagues who steal your ideas. Building features that no one will ever want or need or use because someone, who plays politics well, thought it was a good idea. Getting iced out of critical meetings that impact your work, and require your knowledge base in order for people to make the correct decisions… all because you don’t have the right title in your job.

That’s why I love working with founders who are building put their MVPs; none of that shit works.

The problem is that a lot of founders still haven’t figured that out yet. And why they aren’t as extreme as the gossiping or backstabbing or playing favorites, they still bring in bad habits that they picked up in corporate. And those habits slow their startups down.

Here are some of the things I’ve seen, that you should avoid:

Too many meetings

I get it. You need to keep track of who is doing what, and in what order. The problem is that a lot of founders don’t seem to realize that their job isn’t to babysit their staff. It’s to hire the best people possible for the job, and let them do their jobs. If you can’t trust your staff to operate somewhat without your oversight, you’re going to hit a wall that every founder does - the wall of not having enough time.

Not showing up to enough meetings

In corporate it is incredibly rare to see a founder at a meeting. This is because they’ve scaled the business enough to hire C level executives who can execute their mission.

You are not at that level yet.

In fact, as an early stage founder, you shouldn’t have a C-Level executive. You should have hires who can directly execute your vision; your organization should be incredibly flat. Rankings and levels don’t work at early stage startups. Every hire should be the most senior person you can find, and every hire should be responsible for executing your vision. This requires that you show up to at least 1 meeting a week.

Experimenting with New Technology

I see this a lot with founders who are building with no-code tools. It’s one thing if you’re a big corporation, and you want your dev to to build out a proof of concept that you can show off internally. Using something that isn’t battle tested; something that’s new and might not live up to its promises is fine. Because this product will never get in front of real users, or get pushed to production. Before real users see it, engineers will change it so that it fits their current tech stack.

You shouldn’t be doing that. You should be starting off using the best technologies that you can, so that when users start calling, you can pass it off to a real software engineer.

You don’t want to demo products on new technologies that don’t work because if someone give you their money, you’ll need to get their data on production.

Microservices and Over Engineered Architecture

In corporate environments, this is a great idea. Microservices give us the ability to take complexity and split it into smaller, more manageable pieces. Different teams can own different services, and deployments can happen independintly. One team can move without blocking another. Need to swap out one technology for something better? Microservices make that easy.

This is completely unnecessary for early stage startups because you don’t even know what you’re building yet. Your team shouldn’t be big enough at this stage to benefit from this; it should be too small to manage microservices. And isolating the few engineers you have, and having them all work on different peices of the puzzle; that adds the complexit that microserverses are supposed to remove.

Extensive Internal Documentation

At least once a week I’ll meet with a founder that has 0 customers. But they have pages and pages of documentation.

They document how the product works, what their salespeople should be saying, old bugs, new bugs. Future features that not a single person will ever pay them for.

This is because they’ve worked in corporate for so long that they have the inability ro recognize what this actually is…busywork.

Our corporate overlords love giving people busywork. Especially when there are more important things that need to get done. I have no idea why (if you know please reply and let me know. I’d love to hear your theories.

See you next week,

LaToya