Builder’s Perspective vs User’s Perspective
There’s a natural tension in the act of building a product. We have our projection of who we’re building it for (usually ourselves and not anyone else), what we want to build, what it will do, and how it will be used, etc.
Users have their own projection of what they want us to build, who we’re building it for, what it will do for them, how they will use it, etc.
Bridging that gap and finding the middle ground between these sometimes competing perspectives is why product and product marketing exist. It’s a constant effort in calibration:
Who you think you’re building for doesn’t end up being the only, or many times even your biggest, constituentWhat you want to build is rarely exactly what’s wanted by usersHow you think it will be used is only a subset of how people actually use it in real life
Our imaginations, as builders, are surprisingly small and the number of “corner cases” large — less like corners and more like whole edges we just don’t conceive of.
Communication vs Broadcasting
Getting the calibration right is a matter of communication, bi-directionally, between us and our users. It’s a conversation.
But instead, usually what we’re doing broadcasting things that serve our purposes as builders-and-sellers:
Stating who we think the user and buyer is, so people can rule themselves in/outStating what we think the value is, so people can be convinced they’ll be better offStating what we think the product/solution is, so people can compare the thing to other things and categorize itStating what the technology is, so people can be bamboozled by buzzwords or impressed by our engineering chopsStating what we think the use cases are, so people know how they will experience the valueStating what the pricing or buying process is, so people know how they will consume it
The problem with communication is the illusion that it has occurred. — Jennifer Pahlka, 6th Blitzscaling class
What we tend not to do is communicate expectations:
How do I expect you’re going to use the product?What’s the range of inputs I expect?What’s range of outputs you should expect?What have I imagined you doing?What have I imagined you not doing?Where are the cracks and fissures in the product, in the experience?What should you not be surprised by?How should you interpret the expected and unexpected outputs?How do you think you’re going to use the product?What do you expect it to do when you use it?What don’t you expect?What do you think the value is?
We can’t manage expectations we don’t communicate
Without communicating expectations to, and consuming expectations from, users — we can’t manage them. I’ve found this to be one of the central causes of friction and poor user experience.
Programming notes: this post is n in a series of indeterminate length on Product topics mainly for startup people, mainly leadership, mainly coming from non-GTM backgrounds.
Posts in this series
- Product 101 for Engineers
- Product 102 for Engineers
- Minimum Usable Product
- Product, Marketing, and the Art of Managing Expectations
Related series (and templates) on Marketing
- Marketing 101 for Engineers: A Functional Introduction
- Marketing 102 for Engineers: Roughing Out a Funnel
- Marketing 201 for Engineers: Messaging & Positioning
- Marketing 202 for Engineers: Launching
- Marketing 203 for Engineers: Sales Enablement
- Marketing 204 for Engineers: Generating Demand
- Sales 101 for Engineers: A Functional Introduction
- PR 101 for Engineers
- Analyst Relations 101 for Engineers
- Basic Messaging Template [Google Doc]
- Basic Funnel Metrics Template [Google Sheet]
- Basic Launch Timeline Template [Google Doc]
- Basic Battlecard Template [Google Doc]
- Detailed Battlecard Tempalte [Google Doc]