A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
Overview of what we’ve covered on “Notes on Product Management” so far:
– Overall: The IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, 5 habits – high velocity product teams, Getting in – I, Getting in – II
– Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
– Skill #2 – Selling: Sales and Marketing, Writing for executive audiences
– Skill #3 – Problem Solving: Roadmap, Product specs
– Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture
A product manager brings a team of cross functional stakeholders together to build a product that is valuable, usable, feasible.
Our focus in most previous editions was on solving for value. We spent significant time here because this is both the most important and difficult outcome we need to solve for as product managers. That said, the time has come to spend more time on the other outcomes – usability and feasibility. And, today, we’re going to focus on the next key outcome – usability.
When we talk about usability, our focus will be on the user experience (Ux). An equation I use to think about the user experience is:
User experience = (User Interface + Interaction Design + Information Architecture) x Value
Let’s examine the parts of the equation:
– User interface (UI) = Layouts, fonts, colors, and illustrations
– Interaction design (IxD) = Effects of clicks, taps, and gestures – if you are building a feature as part of a larger product, the interaction design will be dictated by the design system in the product
– Information architecture (IA) = How the entire app/website is organized – if you are building within a large app or website, your product/feature is just one part of the entire user experience. So, every other feature and product plays a part in the user’s experience.
– Value = Both real and perceived value – real value is tangible and perceived value is often a result of the story/narrative/marketing. Both matter.
When you think of user experience in this way, you realize quickly that usability is EVERYBODY’s responsibility. Your design pod may be designing the user interface. But, it lives in the context of the design system and architecture of the entire app or product your user’s experience.
And, finally, value is the multiplier. If a user doesn’t experience value, all other effort goes to naught. Conversely, if you have a high value product, the impact of your UI + IxD + IA increases many-fold.
Think of Zoom as an example. As someone nicely put it – “Zoom’s UI may be average. But, the Ux is top notch.” Put differently, you can complain about the position of buttons on Zoom all you want. But, it works and works beautifully. Zoom’s technology reliably delivers vast amounts of tangible user value. So, any feature Zoom delivers (e.g. virtual backgrounds) builds on top of that powerful foundation.
It is also important to realize that value can be both real and perceived. If you are building enterprise products, a big part of your product’s user experience will be the customer’s experience of your sales force, customer success, and customer support teams. In a consumer product, a user’s experience will include the story that your marketing and communications team tells.
Usability is everybody’s responsibility.
A key part of building usable products, however, is building a product team that cares deeply about usability. I think there are 4 things we can do to make that happen.
(1) Build a strong partnership with your design partner and team.
When you start off as a junior IC, your design pod may look something like this.
Central to this pod is the relationship between the PM and the Design partner. When this relationship works well, it works because of context, trust, and communication (fundamental to all strong partnerships). 3 questions that can help you gauge this are:
(i) Context: Can your design partner talk through the strategy/problem statement/hypothesis/success metrics? What about the timelines – do they feel bought into the level of urgency required?
(ii) Trust: If she were out of the office next week, would she trust you to make user experience decisions on her behalf? And, if yes, would she also trust you to make timeline commitments on her behalf?
(iii) Communication: When you walk out of conversations with each other, do you feel you are on the same page?
These questions point to what we can do to make this a strong partnership. Ideally, our design partners are with us at every step of the problem finding process. They’ve worked with us on defining the problem statement, understand the data, success metrics and business value, and are bought in on the hypotheses we are testing.
We then earn their trust by building in time for creative exploration. That enables our design counterpart to explore multiple possibilities before picking a solution. Taking the time to do this right saves a lot of time later as it ensures we don’t get overly attached to one possibility.
Context and trust make communication easy.
An absence of context and trust on the other hand lead to the two variants of the worst PM <> Design relationships. Misaligned teams find themselves in debates that go on forever without progress. They struggle to make decisions without help from their managers.
And, in teams that lack trust, the designer and his managers see themselves as the guardians of the user experience and view the PM as the (evil) representative of the business. This is the worst variant as it guarantees dysfunction and toxicity.
Understanding how to build strong partnerships in your design pod matters a lot as you grow as an IC because the size of the design team grows as you take on larger projects. Larger projects mean larger surface areas that can involve opportunities to impact huge parts of the user experience. But, it also means dealing with a design team that is a combination of many design pods.
Given this size, it won’t be just you and your design counterpart. Instead, the core team iterating on designs can vary from be a team of 6-10 folks. As an example – until a week or so ago, a design team comprised of 8 met every day for at least one hour for nearly 8 weeks as we worked through designs on a large project.
As the design team scales, the importance of context, trust, and communication continues to increase exponentially. Ensuring everyone has shared context also involves obsessive documentation and planning so everyone understands their role on the team. (We’ll cover this in detail in an upcoming post.)
(2) Make it unacceptable to ship a screen without making thoughtful choices about every aspect of it.
If the designer on the team is the only person obsessing about the user experience and user interface, you have a dysfunctional team on your hands. Every member of the product team must care deeply – for every line of copy, every pixel, and every stress case.
Your design partner will of course be in-charge of decisions on the UI and key parts of the user experience. Your marketing partner will likely be making most of the decisions on the words you use. But, as an IC PM, it helps if you consider it unacceptable to ship a screen without having thought through and debated every aspect of the user experience.
The test for this is: if a user stops you today and asks you why you chose the words you shipped or why you chose to put a button where you put it, it is unacceptable to say – “we didn’t give it much thought” or “that was my design partner/marketer’s decision.”
As a product manager who builds user-facing products, our track record and impact is entirely a product of the screens we ship. And, again, it helps to consider it unacceptable to ship a screen without making a thoughtful choice about every word, image, and, interaction in partnership with our partners on the team.
(3) Pay off your Ux debts – make sure “P1” isn’t short for “will never get shipped”
As you ship the first version of your product, you will have to make compromises. That is just the nature of the game. There is no way you are getting everything you want in your MVP/minimum viable product. Something you want will be too heavy a lift for the engineering team and won’t be worth building till you are sure the MVP is working well. (Conversely, if you are getting everything you want in your v1, it is likely you are not prioritizing well.)
What do you do then? Does that result in an uneasy stand-off between you and your design counterpart? As you mark critical features as P1, do you do it with grudging support? These dynamics make and break relationships within the the product team.
There are three things great teams do here. First, they focus on building MVPs right. Instead of attempting to get some basic version of the product out, they focus on the riskiest assumptions that need to be tested.
(Image credit: Applico)
Next, they align on the “P0” features to test the riskiest assumptions. They do this together. When they find themselves dealing with technical challenges, they go back to the drawing board and prioritize again. Together. The focus on the team is to figure out the best possible path to validating assumptions while still being shipping a product they’d be proud of.
Finally, once the MVP does work, they make the time to ship those P1 features and ensure they make time to pay off their user experience debts. This can be a particularly difficult choice to make in the short term as it is tempting to go shoot for your next metric win. But, craftsmanship matters greatly in the long run.
That’s because investing in craftsmanship means fewer bugs, fewer support tickets, and more user delight. And, it also helps build a high trust relationship between the PM and design counterpart. If “P1” becomes short for “it’ll never happen,” expect lots of disagreements and drawn out arguments when you need to move quickly.
Pay off your Ux debts.
(4) Every time you look at a screen, ask “how can this be simpler?”
You will go into rabbit holes and attempt to over engineer your product. That is guaranteed. When that happens, you will hopefully have surrounded yourself with a team that stops you from doing it.
But, ideally, you stop yourself by asking yourself one question every time you look at designs – how can this be simpler for our users?
Generally, this means –
– Fewer choices for our users to make
– Faster loading time
– Less business logic and fewer variants that help ensure reliability
– Fewer screens
– Clear instructional/direct copy
This isn’t meant to be dogma. There are situations where doing the opposite may be simpler. We once added two extra screens to a complex single screen flow to make it simpler. And, that lifted outcomes by 50%. But, as a guideline, fewer and simpler is better.
We become power users of our product by virtue of the time we spend on it. That isn’t true for our users. They don’t have the context we have. They don’t invest the time we invest either.
If we can just be an advocate for simplicity and build this muscle across our team, our team will win.
As you can tell, this post was intentionally not about choosing the right user interface pattern or testing 30 shades of blue. Of course, if you are working on a product that provides as much tangible user value as Google search from 2005 while maintaining an incredibly simple UI, testing 30 shades of blue may indeed be the best use of your time. :-)
Instead, this post intended to do two things. First, it provided a mental modal to help us think about usability through the lens of user experience. As user experience is a combination of every aspect of the user’s experience of our product, it is everyone’s responsibility. And, as product managers, it is our responsibility to understand that and think holistically as we build features and products.
Second, it is all how we can contribute to the design process – by obsessing about the details as a team, paying off our Ux debts, pushing for simplicity, and building a strong partnership with our Design counterpart.
The PM <> Design relationship is a special relationship as our design counterpart is the creative wheel that brings words on a strategy doc or a whiteboard to life. Given its criticality, it can be incredibly frustrating when it doesn’t work. And, while some part of this relationship is result of chemistry, a significant part of it is a result of the process you follow as well.
Here’s to better process.
