I hate MVPs. So do your customers. Make it SLC instead.

Product teams have been repeating the MVP (Minimum Viable Product) mantra for a decade now, without re-evaluating whether it’s the right way to maximize learning while pleasing the customer.

Well, it’s not the best system. It’s selfish and it hurts customers. We don’t build MVPs at WP Engine.

This is the right way.

Read this article

I hate MVPs. So do your customers. Make it SLC instead.

Product teams have been repeating the MVP (Minimum Viable Product) mantra for a decade now, without re-evaluating whether it’s the right way to maximize learning while pleasing the customer.

Well, it’s not the best system. It’s selfish and it hurts customers. We don’t build MVPs at WP Engine.

This is the right way.

Read this article

Should you invent a new UX?

Using common metaphors makes your product UI identical to all the others. There’s no personality, no brand, solidifying the notion that this product is “just another tool” rather than a new way of interacting with a computer. Surely technology can be better than that.

But this is an egocentric view. Your customers don’t want to figure out some newfangled damn thing just to navigate a dialog box.

Which way is the right way?

Read this article

Finding the right advice

For every clear example that proves “X is right,” there’s another equally compelling story of success where the mantra was “X is wrong.”

So the question is: Which advice is right for me?

Let’s answer that question.

Read this article

Satisficing vs Maximizing

“Maximizing” means expending time and effort to ensure you’ve solved something as best as possible. It typically needs lots of exploration and analysis to ensure “the best” option hasn’t been overlooked, and that we have confidence in our evaluation of all options.

“Satisficing” means picking the first option that satisfies some given criteria. It’s less time exploring & analyzing, more time acting. It’s not getting paralyzed by the pursuit of “perfect,” but it often doesn’t result in finding the very best.

In software and startups we can choose when we maximize, and when we satisfice. It might seem like maximizing is best especially when you have teams of smart people who can do the maximizing. But not necessarily.

Read this article

Not sure?

Whenever you’re dithering, usually the correct answer is the difficult one. The reason you’re dithering isn’t that you’re unsure. It’s that you don’t like the truth, so your emotions are trying to justify the easier path.

But your job is to do the difficult thing.

Read this article

Avoiding the trap of low-knowledge, high-confidence theories

There’s an underlying mechanism that causes us to be falsely confident in our command of knowledge and decision-making. We automatically construct narratives of comprehension, even when our command of the facts is feeble.

Defeating this requires intentional effort.

Read this article

The wrong question: Is now the right time to start a company?

The answer to that question is “yes,” but that’s why it’s the wrong question.

Read this article

Why large companies acquire small companies

Large companies don’t acquire small companies for their financials, because small company revenues won’t mathematically affect the growth or value of the acquirer. Rather, small companies are acquired for strategic reasons, and understanding how that works is the key to understanding how small companies are sold.

Read this article

Look what we did

“You must be so proud of what you created” — the reflexive conclusion delivered by visitors to our building at WP Engine, struck by a beautiful place teeming with energy and activity, coming upon the little office of the founder.

“What we created,” I always respond. It’s not false humility. I didn’t create this. There are over four hundred people creating it even as we speak. I haven’t even been the CEO for three and a half years.

Read this article

Building in public forces true competitive advantage

If you write your code in a public github repo, others will judge your code, with a broad definition of “quality” that includes everything from file and class organization, documentation, tests, avoiding placing API keys in code, eliminating your reliance on “security by obscurity,” and even that artful quality which like the proverbial US Supreme Court definition of pornography is impossible to define but “you know it when you see it.” In this sense, building in public forces you to create quality, artful code.

The force at work is as simple as it is universal: Ego — your desire to impress others.

Can you redirect the same force to create even more valuable outcomes?

Read this article

Laws of 10x found everywhere. For good reason?

We all see patterns, even when there’s only noise. And we like a good story. If the story makes sense, and the pattern isn’t complete nonsense, we see the story as truth, and the pattern as verified.

Maybe that’s the case with the idea that things in startups come in 10x increments.

But I think it’s actually true, or true enough that it’s an excellent rule of thumb that should be assumed until proven false. Here’s a bunch of examples to guide you.

Read this article

Worrying is self-fulfilling; what to do instead

“Worry” causes the very thing you’re worried about, to actually happen.

“Worry” breaks everything, even things which aren’t broken. It doesn’t lead constructively to solutions, it just creates problems.

The opposite of “Worry” isn’t “Apathy.” The opposite is “Planning” and “Preparation.”

Read this article