The Stack Fallacy


By Anush Sharma. There's a lot of good stuff in here that I'll just quote directly:

Stack fallacy is the mistaken belief that it is trivial to build the layer above yours.

Database companies believe that SaaS apps are “just a database app” — this gives them false confidence that they can easily build, compete and win in this new market.

In a surprising way, it is far easier to innovate down the stack than up the stack. 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.

Product management is the art of knowing what to build. The stack fallacy provides insights into why companies keep failing at the obvious things —  things so close to their reach that they can surely build. The answer may be that the what is 100 times more important than the how.

How Cocomelon gets made


From Ezra Klein’s show with Maryanne Wolf about the children’s show Cocomelon

[They] have set up a room, the place that makes Cocomelon, where they will have a kid watching the show. And set up next to it is another screen that shows an adult just doing normal household tasks, just sort of wandering around doing whatever you do in the house. And if the child becomes distracted from Cocomelon by what the adult is doing, they go back to the edit and they amp up the interestingness, the cuts, the whatever makes a Cocomelon episode interesting.

As a product manager, I admire the understanding of the use case and the commitment to execution, but as a parent…

Slack’s eroded value proposition


Over the weekend, I read We Don’t Sell Saddles Here where Stewart Butterfield outlines how Slack plans to take over the world. It’s a great piece and worth reading if you’re planning on launching a new product. It really captures the dynamism that Slack had in the early days.

This part in particular stood out to me though:

The best way to imagine the reward is thinking about who we want our customers to become:

* We want them to become relaxed, productive workers who have the confidence that comes from knowing that any bit of information which might be valuable to them is only a search away.

* We want them to become masters of their own information and not slaves, overwhelmed by the neverending flow.

* We want them to feel less frustrated by a lack of visibility into what is going on with their team.

* We want them to become people who communicate purposively, knowing that each question they ask is actually building value for the whole team.

As someone who uses Slack every day, I had a visceral reaction to each of these propositions. I never feel relaxed when using the app and I almost always feel overwhelmed by the flow of information.

The app became what it set out to fix — in many ways, the reduction in friction, which made it so addictive, made many of the problems it set out to solve worse.

Product is the art of the possible


Otto von Bismark, Chanellor of Germany, who said: ““Politics is the art of the possible, the attainable — the art of the next best”. Image is from Wikipedia.

Sometimes you have the opportunity to give a user an insanely great product. The organizational support, project funding, and technology all line up to give exceed user expectations. These are rare opportunities — enjoy them!

Most of the time you’re missing one of the key ingredients: project funding, technology, or organizational support.

Frequently the limiting constraint is a political one. You can’t launch the new product to all users because the sales team is afraid of how enterprise partners will react. You have to launch sooner than you want because a leader has drawn a line in the sand. A partner team won’t change their roadmap to help you with a dependency.

These political constraints can be the most frustrating because they seem arbitrary. But that doesn’t make them any less real. The best product leaders I know play the long game. They make the case for the best theoretical path, but are willing to accept the best one available. Then they move on to the next iteration. After all, iconic products are built one well thought-out iteration at a time. This flexibility gives them credibility with others, which gives them more space to operate in the future.

It’s common for companies to talk about product managers as mini-CEOs, masters of their own feature set. In many situations I’ve seen, this is actively unhelpful because it doesn’t prepare the product manager or their stakeholders for the reality of what the pm is being asked to do: find the possible, the attainable, the next best.