Learning programming: Building with belief
I heard a recent podcast ask a question about Meta’s Threads app, “Who are they building this for? Twitter people, Instagram people, someone else?”
Fair question since products are built for people and Product Managers are drilled from the beginning to be the voice of the customer, be customer-obsessed, and with user-centric design and all the templates that go along with it.
But there are many situations where customers, research, and data aren’t available or the right way to navigate product decisions. Sometimes all you have is belief.
The answer to the question about Threads and who they’re building it for is: no one in particular. Meta is building Threads with belief. They believe there can be 1B person, text-based social network; they believe they can make it more compelling by understanding people and building better algorithms to show them what they want; they believe they can apply their Infrastructure for moderation and make it a more enjoyable experience. (This is all incidentally why they “copied” Twitter – none of the differentiators above have anything to do with the UI, so why change it.)
Meta must build many things with belief because their products serve a wide range of people — it makes more sense for them to build something and see what happens — but there other situations when it makes sense to navigate with beliefs rather than data.
Build with belief when
Your product is broadly appealing and impossible to describe a typical user (e.g. Threads)
Your hypothesis is impossible to prove with small-scale testing (also Threads).
You’re building something novel people don't have a reference for.
People think your idea is crazy and you have no proof otherwise.
It’s a passion project and the outcome is irrelevant.
Build with data when
You have a narrow userbase that can be described clearly.
You’re iterating on an existing product or feature and have existing data.
Your company culture demands it.
Belief is an uncomfortable because you’re exposed. If the idea flops you’re left to blame. A little user research, a few personas, and some market research provide some protection. It’s understandable why people stretch to find justifications for their beliefs.
“It is much easier to be fired for being illogical than it is for being unimaginative.” ~ Rory Sutherland
The main reason to be clear about how you’re making decisions is maintaining the trust of your team. The worst thing a Product Manager (or any leader) can do is tell their team that decisions are rooted in data and then repeatedly ignore and overrule it. Trust will start to erode because you can’t trust someone who says one thing and does another.
A good Product Manager can navigate with both belief and data as needed: data for near-term decisions and understanding the world as it stands; and belief for the conviction to charge over an uncertain horizon. Most importantly though, they must be good at articulating their approach to the team so they can come along.