I’ve seen Anshu Sharma’s Why Big Companies Keep Failing: The Stack Fallacy come up in my feeds a bunch of times over the last couple of days. I personally found the writing quite confusing, and had to read it several times to figure out what he was trying to say. I even drew a picture to help me.

If I understand the argument correctly, Anshu is saying that wherever your core business is in the technology stack, it’s easier to expand your market by going down the stack than up. Like so:

This is obviously an oversimplification and leaves a lot of things out, but it was just a way for me to make sense of the article. That said, it’s this part in particular that stood out for me:

The bottleneck for success often is not knowledge of the tools, but lack of understanding of the customer needs. Database engineers know almost nothing about what supply chain software customers want or need. They can hire for that, but it is not a core competency.

The reason for this is that you are yourself a natural customer of the lower layers. Apple knew what it wanted from an ideal future microprocessor. It did not have the skills necessary to build it, but the customer needs were well understood. Technical skills can be bought/acquired, whereas it is very hard to buy a deep understanding of market needs.

In other words, it’s easier for Apple to take on Intel than it is for Apple to take on Facebook. Likewise, it’s easier for Amazon (AWS) to take on hardware manufacturers than it is for them to take on Salesforce. And the reason for this is that most companies understand the customer needs of the components their core business is built out of, but they don’t understand the customer needs of the businesses that other companies build using their components.

Update: This tweet from Peter Matthaei is a much better summary than the one I came up with:

.@RianVDM If your company uses something, it’s down the stack; anything that companies can build with your stuff is up the stack.

— Peter Matthaei (@mobivangelist) January 20, 2016

It’s an interesting theory, especially if you consider the logical conclusion that apps and services like Facebook and Salesforce (etc.) are at the top of the stack, and everyone not originally in the software business is going to have a really difficult time competing with them. I’d be curious to hear what others think of this…

Back in my eBay days, when Net Promoter was just becoming a huge deal, there came a time when we were asked to include the measurement in our user research. Even then I was extremely uncomfortable with the simplistic nature of the measure, but I just didn’t have the experience to speak up about it. It seems that NPS is finally getting the wind taken out of its sails. The latest takedown I read is Matt LeMay’s excellent On Net Promoter and Data Golems:

This very ubiquity is a huge part of what makes Net Promoter so attractive. It’s a system with an official-sounding name that consistently produces a measurable quantitative output. The score it produces can be easily benchmarked against that of any other company. And this is why, no matter how many times it is critiqued and debunked, Net Promoter only seems to grow in power and pervasiveness. The primary value of Net Promoter is not how effectively it predicts customer loyalty, but rather how effectively it covers your ass.

The main problem with the NPS question—“How likely are you to recommend [product] to a friend or colleague”—is that it’s a data model that doesn’t fit the social model of recommending products.

But by oversimplifying the multifaceted and highly variable human context around recommendation, Net Promoter falls into one of the biggest pitfalls of the “data-driven” age: it puts forth a data model that does not accurately reflect the underlying social model. When’s the last time you thought to yourself “I am likely to recommend this product to my friends or colleagues” as opposed to something like, “I can’t wait to tell my friend Tricia about this new slow cooker because I know that she doesn’t like to cook things on the stove”?

Luckily, Matt provides some really good ways to improve the use of NPS. Is this is something you deal with in your company I highly recommend his article.

My latest column for A List Apart was published today. From The Analog Revolution:

So I wonder. I wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the product we make might not only be done at some point, but might be something that lasts for a while? Would we make it fit into the web environment better, give it a timeless aesthetic, add fewer unnecessary features, and spend more time considering the consequences of our design decisions?

It’s not the best thing I’ve ever written, but I have to say, it’s one of my favorites. This is something I’ve been thinking about for a very long time, and to condense those thoughts into just over 1,000 words that include subtle references to The Hobbit and Zoolander feels pretty good.

I find the common meme of “Oh, that’s ugly—a developer must have designed that” pretty misguided (and I’m not even a developer). The reason is that most developers I know have exceptional ideas (and taste). So these words from Marty Cagan really resonated with me:

I consider this mindset of the product owner (or more generally, the CEO or stakeholders) as the only one that can determine what to build, as toxic to teams, and a major reason for the lack of innovation. I’ve tried to explain many times that often the best single source of true innovation are our engineers. That doesn’t mean every engineer is going to be like this, but the mindset where no engineers can do this is a very serious problem. The engineers are working with the technology every day and are in the best position to see what’s just now possible. They are also disproportionately very bright people. When you combine this deep knowledge of technology, with a first-hand experience of the customer problems, great products can result.

“The best single source of true innovation are our engineers.” True that.

In my latest column for A List Apart, called The Distance to Here1, I discuss a theory I’ve had for a while now:

The larger the distance between people who build a product and people who make decisions about the product, the harder it is to make a good product.

The post goes into detail on how I think companies can continue to make good products as they grow.

1. Anyone else old enough to get the reference? ↩