Pursuit of perfection impedes perfection itself

I don’t believe in perfection.

No product has ever achieved perfection. Even the bible, one of the longest existing products I can think of, has hundreds of versions and multiple translations of the thousands of manuscripts that have been created. There is no total agreement on which version is the best or most accurate, or therefore, the most perfect.

To use a more modern example, Apple and Amazon have essentially endless capital and talent, yet any person who uses the product every day could rattle off half a dozen ideas on how to improve the product (for me, I’m dying for Apple to improve their operating system’s search tool—it’s terrible).

Whether it’s the bible, the everything store, or the latest iPhone, a leader somewhere decided it was time to launch.

And the best leaders know when it’s time to ship, and when revisions are necessary.

There is a point in every project where questions come up of “should we fix this before launch?” Teams will often want to spend time (and therefore money) fixing everything and building a really strong minimum viable product (MVP). I don’t think it’s bad to have these types of team members—they care about their work and want to build awesome stuff. But without a system and goals, this mindset of getting a launch closer to perfect can unravel a host of problems.

This must start with a visionary leader. In my opinion, it’s not the role of the project manager, engineer, designer or whatever role is involved in your project. A strong leader must scope the vision of the product, and decide what components get left behind, and what makes it into the MVP.

I learned the worst way the hard way

I learned the tenants of project management while working in advertising agencies. Agencies are notorious for executing the waterfall method, which effectively leans on completing each phase of a project in totality before moving onto the next.

For many projects, this would mean:

1. Define requirements / scope the problem

2. Analyze the problem / define solutions

3. Design solution

4. Engineer solution

5. Test product

6. Launch

Agencies prefer this approach because it requires client’s to sign off on each phase. You’re limiting revisions this way, and honestly, it’s a lot of CYA-ing along the way.

You can scope an agency-built product with an agile method, but it’s more fluid and therefore harder to define at times. Fluid situations can be a nightmare for client satisfaction. I do know a few agencies that are successful with agile methods, but they’re few and far between.

Both of the agencies I worked for ran waterfall methods for all of the reasons I just mentioned. Sure, we could update a product if the client changed their mind later, but generally, we ran waterfall because it minimized revisions and made us more money.

I’m now running a startup, and I’ve found that waterfall just doesn’t work when you’re building a product in-house for a company that’s still finding its footing. From what I know of you, dear readers of Silicon Holler Founding Father, you are in the same boat.

Alternatively today, we use a more agile method of development. Agile development is all about delivering small components of a product at a time. This method uses adaptive approaches, organized communication and strong teamwork to continuously evolve a product. GoWild, our app, as an example, has literally gone through hundreds of minor changes, and about 10 major product changes since launch.

My latest example of scoping tight

When we started building Holler Commerce, our new product that I wrote about recently, we used the agile methodology. Before we could scope anything, we had to have a vision for what the product would be. That was my job, and I leaned heavily on my cofounder Donovan to help define what the product’s design would be.

We created Holler from a mere idea—what if we white labeled GoWild’s tech to allow others to tap into our social commerce tech? We came up with this concept of Social Commerce as a Service, but still, we had to have a vision for what this would be.

Components of this vision:

• Clean dashboard for Holler partners to log in for brand access, analytics, customer data, etc.

• Ability to launch new brands with the press of a button

• Segmentation of each Holler partner’s data—this would not be a single sign on product (this one endured much discussion internally)

• Turnkey service from start to finish

• Super simple integration for the partner’s tech team—I mean stupid simple

• Modular dashboard, allowing Holler to launch new modules/features that instantly update in the dashboard without an update (beehiiv is crushing this approach)

Once I scoped out what I wanted with Donovan, my cofounders Chris and Zack went through and did an extremely thorough scoping of the tech requirements with our engineers. Many oversights came up—things I had not through through well enough or didn’t know to even think about. There were many things the team wanted to add to Version 1.

Some we did.

And some we didn’t.

There were ideas that came up that were critical. Others were not. At the end of the day, I had to decide to cut many product features that would have been great, but they would have added weeks if not months to the launch. Speed is the absolute most important thing for Holler right now, so I had to make the hard decision to launch a product that’s far from perfect.

But Holler will never be perfect.

I truly don’t believe perfection exists in business.

There is always a way to improve average order value, time on site, butts in seats, conversion costs, or whatever metric is critical to your brand.

When working on projects of this size or even a small project you’ll turn out in a few days or weeks, it’s critical to decide what your vision is going to be for the project, to scope it tight to that vision, and draw the line at what has to come in Vs. 2—or it can even be Vs. 1.1.

We do this all the time with GoWild, and the funny thing is, we often kill ideas we had for the next version because here’s the thing:

By getting live with the MVP, we find that our hypothesis about how people would use something was just flat out wrong. I’ve killed many products we’ve built, ranging from an activity tracker on the app to an RSS reader for outdoor news, because people just didn’t use it like we thought they would.

Getting to market fast gets you the most critical thing you need for testing—users.

There’s an old saying, “Nothing makes a bug pool shallow like users.”

But getting live quick is dependent on having a great leader who can envision exactly what Vs. 1.0 will look like, and hold the team to a tight scope. Yes, your team will have things they want to include in Vs. 1, and sometimes they’ll be right. Sometimes they won’t be. Or sometimes they will be and you have to cut it anyways to stay on pace.

Leaders, don’t underestimate your role as the captain of the ship. If you want to build something awesome and meaningful, you often have to launch with something far short of the endgame potential. Embracing a lean MVP is not a shortcoming—it’s a strength.

3 tips for creating a focused vision & scoping a tight MVP

1) Stay agile

The agile process works very much like a waterfall process, with one primary exception—you’re planning many versions of this process in sprints. You will still define the problem, design and engineer the solution and test. But you’re going to do this in sprints over and over, continuously adding to the product with what you learned from the last version.

2) Know it’s OK to be wrong

For leaders, this process requires you to be open to the fact you may have made some wrong bets—that’s OK. It’s part of the process. It’s better than running a long waterfall process and launching something that just doesn’t work. At that point, you have a ton of time invested in a product that didn’t work. It’s best to take small bites and realize something isn’t sitting well than to try and eat the whole whale at once.

3) Create the vision, but get feedback

Just as I noted with Holler, you have to take feedback from the people who are actually going to build the product. There were many times my team said, “Hey, I know you want to do it this way, but here is the challenge I see with that.” Sometimes I talked through this, and we realized that the challenge was an acceptable loss for Vs. 1, and we’d fix it later. Sometimes it meant changing the entire scope. Scoping well is key to running a successful build for any project.

Who I’m listening to: Nat Myers

What I’m reading: “Leonardo da Vinci” by Walter Isaacson

Follow me for mid-week updates:

LinkedIn | TikTok | GoWild | Twitter | YouTube