Welcome. Product, Briefly is a collection of one-page briefs about building products and the people who create them, drawn from two decades of work in new ventures spanning a breadth of industries. Each one can be read in five minutes and discussed for an hour. They cover cover different facets of Product work while also serving as examples of the form.
It’s built to be taken apart: use what fits straight away, draw inspiration from the collection, make the rest your own. Take a brief, or make a brief.
| productbriefly.com | Briefs | Perks | About | Work with Me |
Language unifies teams
Product development is interdisciplinary, with teams spanning design, engineering, marketing, and more. As AI and new technologies add complexity, the cost of miscommunication between experts grows exponentially. Teams that develop a shared language move faster, build better products, and create more value - while those who don't waste time and resources talking past each other.
Selling in the language of your Customer was an early lesson for me in Sales and for marketing. Seemed obvious: tell your customer what’s on offer and negotiate in their own terms. Using your own internal language just confuses a Customer, things get lost in translation, and the deal doesn’t happen.
The revelation on actively building internal team language happened when I was Product Manager at a company that was overtly “experience-led.” There, the entire organization had adopted this way of speaking about everything surrounding the Product - from how it’s defined, to how tradeoffs are made, to how it’s sold and supported - in the language of Customer Experience.
This wasn’t actually pushing groupthink or enforcing uniform terminology.
Instead, it was about creating shared understanding that let experts communicate their deep knowledge effectively across disciplines. Engineers could advocate for technical decisions through the lens of experience, while designers could articulate their choices in terms of concrete customer value.
This pattern of building shared language became a key of creatig high-performing teams everywhere I worked afterward.
Share language
“You can’t really communicate unless everyone knows what the nomenclature is”
Unify experts
Experts inside of a field have their own shared language, shorthand for concepts that are complex and nuanced, ways of describing their shared perspectives of what they see and how the world works.
Product teams are interdisciplinary, bringing together diverse experts; but how can teammates bridge their nuanced expertise across those domain boundaries to work effectively together?
Done poorly, there’s lots of eye-rolling as people talk past each other: Designers get frustrated because Engineers can’t see past what’s functional, Engineers get stuck on performance metrics that Marketers don’t think has any customer value, etc. Translation errors can be expensive.
Done well, Engineers agree with Designers about ways to elevate the experience, and Marketers and Engineers collaborate to prioritize performance that helps a product stand above its competition.
Language is thinking
Communication on the best teams is seamless: no gaps, no room for misunderstanding, no dumbing down. This is how to make the most of a team’s collective intelligence. Product story, aesthetic considerations, and technical trade-offs all become things the team can think together on, debate, and resolve because it’s all within their shared understanding. If you’re a Product person spending time acting as a translation layer between different disciplines, then they are not speaking the same language.
Each product has its own language, and everyone on the team will learn and contribute to advancing it. This is sometimes established at the company-level, or absent that, can be done at the team-level. Typically, it’s rooted in how people will buy and use the product. However, the team defines the language, not the Customer.
Product language typically draws from three sources: the User, the Customer, and the Ecosystem; in some cases, such as a consumer product, User language alone might be enough.
User-driven. Start with an actual human who has to interact with your product - in the case of consumer products like B2C web or Consumer Electronics, this is the end User; for something like Industrial products this might be an Installer, for instance. Detailed descriptions of User Experiences, beyond Agile Stories or Jobs to be Done, are great here. How does this fit into their life? What is the person thinking/feeling/doing before/during/after using the Product?
Customer-driven. If you’re in a B2B or industrial Product, or operate in a Sales-driven company, you might be focusing on Features and Value - which can be a good thing. There’s still a human on the other end that needs to work with it, so best to consider Users as well.
Ecosystem-driven. Mature industries and highly competitive sectors will have their own language, and often this is the default for teams building for them. How will you talk about it on the press tour? This is the Ecosystem language.
Evolve your dialect
Where is translation most frequently needed? What experts are talking past each other?
When do people from different disciplines use the same terms? Use these building blocks.
How do people outside of the team talk about the Product, from Executives to Support?
Originally published on productbriefly.com
Talk together now
If your team is wasting time translating or there’s miscommunication happening, use this brief to start changing the conversation.
