Solving for usability

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.

Light and knowledge

Diwali, in Hindu tradition, is the festival of light. It was among the most special festivals growing up because it brought together people, good food, and fun in a special way.

On Diwali day, we meet our loved ones, eat delicious food, and light lamps as a collective reminder that light and knowledge triumph darkness and ignorance.

It is a tradition that feels particularly important this year. We’ve all dealt with a vast array of challenges this year and, for many of us, can’t even meet the people we love. Everyone has been hurting in some way.

So, it is worth reminding ourselves that even this will pass. Given time, knowledge and light will shine a way through.

Hope you continue to stay safe and well.

Happy Diwali to you.

I wonder vs. this is what I think we should do

After identifying a potential opportunity recently, I wrote an email to a few folks with the phrase – “I wonder if we should do xyz.”

I got feedback from someone who works closely with me that my use of “I wonder” could be interpreted as passive aggressive and inauthentic. Their advice was – “Don’t say I wonder if what you are really saying is This is what I think we should do. Say it as it is.”

It was great feedback because that wasn’t my intention – my subconscious instinct was to try to be polite. But, I could see why the attempted politeness could be perceived as inauthentic. Say what you mean – as often as possible.

Well-timed feedback is a wonderful gift.

Ronald Read

I love every reminder I can get about the story of Ronald Read.

Ronald Read worked as a gas station attendant and janitor at JC Penney’s. He was known to be a frugal man. After losing his wife at 50, he lived alone for the rest of his life and enjoyed chopping wood.

After his death, folks in his community realized he had left two million dollars to his stepchildren and an additional six million dollars to local library and hospital.

How? He consistently invested his savings in (an eventual portfolio of 95) blue chip companies whose businesses he understood and held their stock for the most of the rest of his life.

There are many fascinating lessons from his story – making a life by what we give vs. get, the importance of savings rate, time in the market vs. timing the market, etc.

But, to me, one that always stands out is the transformative power compound interest can have in our life. Small consistent investments in all important areas of our life – health, money, learning, relationships – compound in magical ways over time.

Here’s to making one such investment today…

Noticing that inner disturbance

Pay attention now:
No matter how much you know or learn about syntax, grammar, and rhetoric,
This small internal quaver, this inner disturbance,
Is the most useful evidence you’ll ever get.
Someday, you’ll be able to articulate what causes it.
But for now, what’s important is to notice it.
Noticing is always the goal.
Actually, the goal right now is noticing that you’re noticing.
One day merely noticing will be enough.

<a few sentences later>

Soon you’ll know exactly how to find the things that are going wrong
As well as the things that are going right.
But until then – and even long after – you’ll find it easier to detect a problem by the disturbance is causes you.

Verlyn Klinkenborg in “Several short sentences about writing”

These notes are about writing. But, they could easily have been about decision making .

Much of learning how to make better decisions in our lives is listening for that disturbance within. We may not always know why. But, noticing and listening to them saves us a lot of pain and heartache in the long run.

“Noticing is always the goal.”

Indeed.

Out of ideas

Every once a while, I find myself out of ideas for the day’s post.

So, I inevitably find myself scrolling through my favorite feeds, going through my Feedly, and/or just clicking about hoping for some serendipitous inspiration.

It works from time to time.

Often enough for it to be something worth trying.

That’s until I remind myself that the solutions I seek are probably not out there.

Instead, they lie within.

I just need to remind myself to pause, take a deep breath, and think.

Socrates’ legacy

I’ve begun reading “The Socrates Express” by Eric Weiner.

Eric Weiner’s style is to take us on a journey around the world and make us smarter about something with a healthy dose of humor along the way. In this book, that something is philosophy. Every chapter in this book is thus about a famous philosopher and their contribution to philosophy.

At the end of a chapter about Socrates, he made an interesting observation. Nearly every great philosopher made their impact by sharing powerful observations about the world and the human condition. They had their own distinct style and approach to making these observations. Some did it with a lot of emotions, others with characteristic pessimism or self deprecation, and so on.

Socrates, however, was unique in only leaving behind a method. Socrates’ legacy isn’t about what he wrote. In fact, he wrote almost nothing. Everything we know about him is thanks to his student Plato,

His legacy, instead, is defined by his approach to thoughtful conversation – the “Socratic method” that relies on questions to spur critical thinking.

It is a powerful way to think about legacy. A legacy that is defined by the how instead of the what.

Soaking in lessons

My notes for the day in the past four days came from one speech.

I wouldn’t have done this a few years back. I would have posted all four anecdotes in one day.

It is one speech after all. Why does it need four posts?

I’ve come to appreciate the importance of soaking in lessons. I could have shared all four stories in one post but I’d have forgotten about them just as quickly. By thinking about these lessons every day for four days, I’ve absorbed them better.

It can’t end here either. I need to re-tell these stories a few times to others and write about them some more. Assuming I do that, maybe, just maybe, I’ll remember them at a time when I need them.

Maybe I’ll remember that I shouldn’t get too upset about being a sugar cookie for the day or to sing when I’m up to my neck in mud.

And then maybe I’ll remember these stories again in a similar situation the next time. And again.

I will only have learnt these powerful lessons when they become part of how I operate. To learn and not to do is not to learn.

Soaking in them is a helpful first step in that process.

Circuses and changing the world

Today’s post is 4/4 in the series on Admiral McRaven’s wonderful commencement speech at UT Austin (click for part 1/4, 2/4, and 3/4).

Every day during training you were challenged with multiple physical events — long runs, long swims, obstacle courses, hours of calisthenics — something designed to test your mettle. Every event had standards — times you had to meet. If you failed to meet those standards your name was posted on a list, and at the end of the day those on the list were invited to a “circus.” A circus was two hours of additional calisthenics designed to wear you down, to break your spirit, to force you to quit.

No one wanted a circus.

A circus meant that for that day you didn’t measure up. A circus meant more fatigue — and more fatigue meant that the following day would be more difficult — and more circuses were likely. But at some time during SEAL training, everyone — everyone — made the circus list.

But an interesting thing happened to those who were constantly on the list. Over time those students — who did two hours of extra calisthenics — got stronger and stronger. The pain of the circuses built inner strength, built physical resiliency.

Life is filled with circuses. You will fail. You will likely fail often. It will be painful. It will be discouraging. At times it will test you to your very core.

But if you want to change the world, don’t be afraid of the circuses.

In each of these stories, Admiral McRaven refers to wanting to change the world. He had a nugget on that too.

“Tonight there are almost 8,000 students graduating from UT. That great paragon of analytical rigor, Ask.Com, says that the average American will meet 10,000 people in their lifetime. That’s a lot of folks. But, if every one of you changed the lives of just 10 people — and each one of those folks changed the lives of another 10 people — just 10 — then in five generations — 125 years — the class of 2014 will have changed the lives of 800 million people.

800 million people — think of it — over twice the population of the United States. Go one more generation and you can change the entire population of the world — eight billion people.”

Awesome speech. Thank you, Admiral McRaven, for putting together this masterpiece.