Laurent-Pierre Baculard makes some great points in WhatsApp Grew to One Billion Users by Focusing on Product, Not Technology:

Examples such as WhatsApp demonstrate that real-world innovation, in many ways, looks like an assembly line. At one end is a customer pain point or a potential new market. At the other is a product or service that solves the problem or addresses the market in a way nobody has thought of before. In between, people sit down and force themselves to examine the problem from a variety of fresh angles. Sometimes they tap the lab and bring a radical new technology to bear. But much more often they reach for pieces of technology that already exist and assemble them with new (or old) capabilities to produce a solution that turns the pain point into a delighted customer. Think of it as high concept meets whatever is lying around — an unconventional combination.

The problem comes when we reach for technologies that seem “cool” but can’t actually be linked to any real customer problem.

Yes, after a long break I’m giving the blog another shot. Let’s see how it goes…

I enjoyed answering some questions about prototyping and Product Management in startups from the nice folks at Justinmind recently. Among other things I got an opportunity to share my thoughts about a particular phrase we hear a lot about Product Managers, one that I think is quite dangerous for our profession…

What kind of challenges and opportunities face Product Managers in a software development context?

I think the Product Management role is still incredibly misunderstood (and misused). I’ve never liked the “We’re like mini-CEOs of the Product” thing you often hear. Any metaphor you come up with that implies a hierarchy (such as air traffic controller, shepherd) gives Product Managers an incorrect view of themselves as The Boss™, and serves only to alienate teams.

We might be the final decider on some issues, but it’s not because we’re “above” the team. It’s because our jobs are to know about user needs, business goals, technical needs, and how all of it comes together in a successful product. Our jobs are to listen to our teams in their various roles and make sure that everyone knows what they need to know. And then our jobs are to walk with the team in a direction that everyone understands and agrees on. It’s not “here are your requirements, see you on the other side of design!” We still see way too much of that in the industry.

Until we change that perception, which will require a change in attitude from us as product managers, we’ll continue to be viewed as obstructionists in many companies. Maybe the best metaphor to use is that we’re servants. Servants to our customers, our teams, and the product. That’s the opportunity we have to bring value.

You can read the full interview here.

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…

Courtney Martin’s essay on The Reductive Seduction of Other People’s Problems really got to me. She makes the case that instead of traveling all over the world to solve social problems in other countries, we should focus on the problems at home:

The reductive seduction of other people’s problems is dangerous for the people whose problems you’ve avoided. While thousands of the country’s best and brightest flock to far-flung places to ease unfamiliar suffering and tackle foreign dysfunction, we’ve got plenty of domestic need. […]

I think there is tremendous need and opportunity in the U.S. that goes unaddressed. There’s a social dimension to this: the “likes” one gets for being an international do-gooder might be greater than for, say, working on homelessness in Indianapolis. One seems glamorous, while the other reminds people of what they neglect while walking to work.

Her proposal is worth considering:

There’s a better way. For all of us. Resist the reductive seduction of other people’s problems and, instead, fall in love with the longer-term prospect of staying home and facing systemic complexity head on. Or go if you must, but stay long enough, listen hard enough so that “other people” become real people. But, be warned, they may not seem so easy to “save.”