Product Management is Communication
Product Management is Communication
Product managers need to speak multiple languages: Design, Dev, User, Boss Talk and more to be successful. (#75)
Today’s post is sponsored by:
Building great products is hard. The echo chamber of navel gazing in product management doesn’t help. It feels like product management is facing an existential crisis. I get it, but it’s nonsense.
Products still need to get built.
People build products.
AI helps. 😀
Perhaps one day AI will do most of the heavy lifting (maybe it’ll proactively build solutions to problems it identifies we’re having, which is cool and scary at the same time). For now, products are built by people, typically as a team.
Teams are effective when communication is clear, precise and constant
Clear, precise & constant communication takes work
Product managers should do that work, because product management is communication. Everyone needs to communicate; product managers are the ones that foster it across teams.
This is why I believe three things:
Product managers need to get their hands dirty and actually build product
Product managers need to understand how things are built
Product managers need to speak “design” and “tech” (although not fluently)
Get Your Hands Dirty
The term “product management” is a problem.
“Management” implies overseeing things, guiding people to do their jobs and assessing their performance. Managers keep things moving (schedules, budgets, resources) but they don’t do anything. They don’t get their hands dirty in the product. Managers manage the people who do the actual work. 🤮 😱 🤬
If you want to be a product manager, build stuff.
You don’t need to be the world’s greatest designer, but you can learn how to do mockups/wireframes
You don’t need to code, but you can definitely experiment with no-code tools, learn how to build clickable prototypes and dabble in hacking things together
In both cases you’ll do a better job of bringing things to life—which is great for communicating effectively—and have a better understanding & appreciation for what designers and developers do (again, leading to better communication).
Understand How Things are Built
Product managers need to understand what it takes to build products beyond the process. Moving tasks around a schedule doesn’t count. What’s actually involved in developing a feature? How is software shipped, hosted and scaled? How do APIs work? Etc.
The more you understand what’s involved in building software, the better you’ll be at scoping & designing it. You’ll know:
When something you’re asking for takes 1 day versus 100 days
How to adjust scope to reduce it and still solve a customer’s problem
Where the code gremlins live and tread lightly in those spots
When a UI is built using best practices and usable or not
Product managers can’t be great at scoping work if they don’t understand what it takes to do the work. Without that knowledge, you’re building stuff with no constraints. There are always constraints—some good, some bad. “Pie in the sky” product scoping/designing is deadly. You avoid it by understanding what you’re asking for, and pre-emptively finding simpler ways to get things done.
Building Mobile UIs at VarageSale
VarageSale was the first company I worked at that was mobile first. I had invested in mobile first startups before, but never been as actively involved in building one.
I joined VarageSale to lead product. So one of the first things I wanted to do was build product. I can’t remember what feature we were building, but I remember mocking it up (trying to “speak the language of design”) using a desktop reference, because that’s what I knew. The team was not impressed. It quickly became clear that I wasn’t fluent enough in mobile design.
I had to engross myself in a bunch of mobile apps, learn what worked and didn’t, read app reviews, do research into UI/UX best practices and iterate a lot with the team. We also had distinct designs for iOS and Android, which meant more learning. Eventually I got there and became comfortable/fluent enough in mobile design that I could articulate what I was trying to do quickly and effectively. It made communicating with the team much easier. That led to us building better product.
Speak the Right Languages
Great product managers don’t have to be fluent in design or development, but they have to converse in both. This comes from doing the work yourself (or at least hacking your way through it!) and understanding what’s involved (which comes through exposure + sets and reps).
I can’t look at code and necessarily understand what it’s doing. I don’t need to. But I have to be able to intelligently discuss & debate with developers to find the right solution and streamline things to achieve our goals. That means I need a basic understanding of the architecture, how long certain things take to build, and awareness of technical limitations (or possibilities) that exist.
I don’t need to be a Figma wizard, or a UX guru, but I need to be able to take written requirements, panicked asks from a salesperson, or “requests” from the boss and translate those—visually—for a designer. Why? Because designers speak in images. And since I need a designer to work their magic, I need to speak in images too.
Great product managers aren’t trying to do other people’s jobs, they’re trying to make their jobs easier and more effective through communication.
Design and Dev aren’t the only two languages a product manager has to be competent in. There’s also:
Metrics: The language of numbers. You need to understand which metrics matter and why, and how to communicate using numbers. Data is a key communication tool.
Sales & Revenue: Salespeople call this the language of love. Money talks. Here’s the thing: product managers aren’t building products, they’re building businesses. And if you don’t “speak business” (including sales/revenue, marketing & customer success) you’re in trouble. You’re probably shipping a bunch of stuff that’s not moving the needle.
Boss Talk: We all have bosses. Product managers are often sandwiched between them and everyone else, especially in early stage startups when the CEO was/is in charge of the product. I’ve often found myself translating between bosses and others, but also figuring out how to push back and challenge the boss, because what they want isn’t always the right thing.
User/Customer: This is the most complicated language of them all. Product managers need extreme empathy, along with a PhD in interpretation to figure out what users actually need and how to give it to them.
Product managers are stakeholder managers. In order to be a great at managing stakeholders you have to be able to speak all of their languages and translate between them.
And now a word from our sponsor…
Become a Business Idea Machine
Half Baked is the world’s #1 business idea newsletter.
Get an original business idea delivered straight to your inbox daily.
Join +10,000 others with hundreds of ★★★★ star reviews.
Sign up here with one click and get 5 ideas instantly.
”I come for the business ideas, stay for the memes” - Michael M.
“I can’t believe this newsletter is free” - James S.
How I Communicate (read: Build Product)
Currently, I’m working on two early stage products. Through the venture studio model, I take a hands-on approach, which means stepping in to different roles whenever needed. I enjoy getting my hands dirty and building stuff. Here’s my process:
1. Write down the high level objective, scope, key features & questions
The first thing I do is write stuff down. I think better through writing. The first document isn’t a Product Requirements Doc (PRD), it’s higher level than that.
My goal is to answer a few questions:
What is the high level objective of what we’re building? Why are we building this thing? This ties us back to the mission/vision and the problem we’re trying to solve. Everything you build should align to the mission/vision and problem.
What is the overall scope? I like to define a high-level scope with some key parameters. For example: a mobile app that does X and Y. You should define the overarching technical elements, and you can even include the must haves. You don’t want to get too far into the weeds without basic team alignment.
What are the key features? Next I define the key features—what I believe will make up the MVP. This typically leads to good discussions with the team. Do we really need X or Y? The whole team can review from their own perspective, with their own language, and provide input.
What are the key questions or unknowns? Finally, I tackle the questions & unknowns. Typically there are a lot of them, and that’s OK. I try to think of every question/unknown possible, because it encourages the whole team to communicate and help us make decisions.
Feel free to dig into the key features. Often when describing features I add:
The feature’s goal: why we believe it’s important (for the user and us)
How it works / user journey: roughly what the feature will do
What has to get built: a quick description of the solution (with some technical elements)
Metrics: what we track to determine if the feature is creating value
Don’t go into every detail, but put in enough—especially related to the key unknowns/questions—to encourage people to give feedback. Too little detail and people either take over to scope features on their own (when they shouldn’t be) or they don’t respond (because they don’t know what to say). Too much detail and people nitpick.
2. Mock things up
Pictures aren’t always worth a thousand words, but it’s worth trying. Use visuals to communicate. Each team member will take their own perspective on the design. Developers will think about how hard it is to build. Designers will think about translating the sketch into a UI. Users will give feedback on what they like/don’t like. Bosses will tell you if you’re translating their vision effectively.
When in doubt, draw stuff.
What should you draw? It depends.
Wireframes (including very simple ones) are great for bringing a feature to life, making sure it fits into the existing product and discussing how it should work from a user experience perspective.
User journeys (i.e. process maps/systems diagrams) are great for understanding the steps a user will go through and how something will work, without focusing on the UI. I almost always draw user journeys for multi-step processes.
You can also use existing examples (including competitors) to demonstrate what your product could look like. Don’t re-invent the wheel. You’re using these images to refine scope, reduce unknowns and secure alignment with the team.
3. Write out PRDs (if necessary)
Product Requirement Documents are a great way to define the full scope of a feature (or MVP). Some templates are quite high-level, others are very detailed. I lean towards the detailed side of things, but try not to overdo it. It’s easy to get carried away writing every little detail. For some features, a visual + high-level description suffice. Don’t over-engineer the process for the sake of thorough documentation. That’s not good communication.
4. Create Proof-of-Concepts (POCs) (if necessary)
Sometimes it’s worth building a POC or prototype. Sketches, static images or docs may not be enough. I find this true for back-end systems or processes.
For example, I’m working on a news aggregator that will find timely content (about a specific topic) and share that with the team. Each week we want to send 3-5 valuable links to users. There are very sophisticated ways of doing this, but we’re hacking it together through Google search, a list of trusted sites, Zapier and a few other tools. Before we launch the newsletter we want to prove that we can find high-quality news on a weekly basis. If not, the feature makes no sense. A simple POC does the trick. If it works and creates value we can add much more (i.e. up/down voting, automated newsletter creation, personalized recommendations, etc.) For now, we keep it simple.
Clickable prototypes are also worthwhile for bringing features to life. A wireframe isn’t always enough to get a feel for how something will work.
5. Prioritize the work
Finally, we prioritize the work. When first defining a Minimum Viable Product (MVP) you have to put a line in the sand and say, “We believe that’s the right feature set to solve the problem and create value on a frequent enough basis.” Don’t get caught adding too much. Scope creep kills all things.
A lot of people dislike the term MVP. I’m not one of them. You just have to define it properly. Here’s how I define MVP.
There are a few prioritization frameworks you can use, including RICE, t-shirt sizing, etc. This is one of those moments when you’re talking every language simultaneously. Developers will have strong opinions on how long things will take. Bosses will want everything yesterday. Sales may have promised new features to customers. Etc. The stakeholder management at this stage is high.
The one language that can rule them all: Metrics.
Data, if implemented properly and communicated consistently & simply, is a universal language. The data is rarely perfect or sufficient (especially early on or pre-launch), but start teaching the language of Metrics to everyone as quickly as possible. If the team isn’t aligned on the data, you’re in big trouble, and it might not matter how fluent you are in any other language.
Collaborating with people is the key to success. Here’s a deep dive on how to successfully work with software developers.
After all of this is done, you move into actual development. Your communication skills need to remain top-notch throughout the process, because your job is to shepherd new features through to users/customers. This is an iterative, often messy and bumpy road. New priorities will emerge. Bugs will rear their ugly head. The boss may decide she wants to go in another direction. You can never control every variable. So you communicate. And communicate some more. As soon as a product manager stops communicating with any of the key stakeholders, in any of the languages they like to speak, trouble looms.
Product Management is Communication
Being a great product manager means you’re a great communicator.
You don’t coddle people, or kowtow to everyone’s needs. Quite the opposite. Because you’re the only one that speaks everyone else’s language, you have considerable power and control. I don’t believe in “management without authority.” Product managers have to be great influencers, but without some degree of control, and respect from teammates (because you speak their languages) you can’t get anything built.
Great communication does not mean more meetings. If you can build things (create assets such as documents, wireframes, POCs, etc.) independently, these become your communication tools. If you can’t—you book meetings.
Product managers get caught (and lost) when they can’t speak the right languages.
They don’t know how to visualize things and must rely on designers. This creates friction and slows down the planning process.
They don’t understand how long things take to build, so they rely on developers, and can’t creatively & intelligently simplify scope.
They don’t know how to use analytics, so everyone tracks their own numbers and nothing makes sense.
Suddenly product managers can’t actually design and build product, which is their job.
Learn the languages. 🤟
Communicate constantly. 💬
Get your hands dirty. 💪
Win. 🏆 🎉