Advice from Jason Cohen, founder of WP Engine & Smart Bear Software.
Though inevitable, change is uncomfortable and exhausting. Even we who relish change, who love bragging that “it’s hard but every day is different,” reach a breaking point after years of adaptation and fake-gleefully exclaiming that “failure is how you learn!” Yeah, but all this learning is fricking tiring.
How do you manage change?
Though inevitable, change is uncomfortable and exhausting. Even we who relish change, who love bragging that “it’s hard but every day is different,” reach a breaking point after years of adaptation and fake-gleefully exclaiming that “failure is how you learn!” Yeah, but all this learning is fricking tiring.
How do you manage change?
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.
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?
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.
“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.
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.
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.
The answer to that question is “yes,” but that’s why it’s the wrong question.
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.
“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.
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?
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.
Look for this icon in my blog posts for the audio versions, or subscribe to my iTunes podcast feed.
