Assiduity

Assiduity means constant or close attention to what one is doing.

I chuckled when I heard it is one of Charlie Munger’s favorite words thanks to his literal sounding interpretation of its meaning – “Sit down on your ass until you do it.”

Here’s wishing all of us some assiduity today.

Fixing the pedal

My wife and I were attempting to fix the pedals back on our kid’s bike today. We struggled and fumbled around for about two minutes.

Despite all our efforts, the pedals just didn’t seem to be going in.

Then, my wife spotted that we were each attempting to fix the pedal designed for the opposite side.

30 seconds after exchanging pedals, we were all done.

It was a good reminder that applying a lot of effort in wrong direction can never compensate for taking the time to think through the right direction.

Spend more time figuring out how to do the right thing vs. doing the thing right.

Making sentences

Why are we talking about sentences?
Why no talk about the work as a whole, about shape, form, genre, the book, the feature story, the profile, even the paragraph?

The answer is simple.
Your job as a writer is making sentences.
Most of your time will be spent making sentences in your head.
In your head.
Did no one ever tell you this?
That is the writer’s life.
Never imagine you’ve left the level of the sentence behind.

| Verlyn Klinkenborg in Several short sentences about writing


Fundamentals.

They form the basis of any and all expertise we build.

“Never imagine you’ve left the level of the fundamentals behind” is an important reminder – no matter the craft.

The amateur player pool table conundrum

An amateur player on a pool table faces one particular choice often – do I focus on just hitting this ball in? Or, do I try to hit it while setting up the next shot?

(Image credit: Unsplash)

There are trade-offs either way.

If I focus on just the ball in front of me, I could hit it in a way that makes it impossible to land the next.

And, if I’m focused on landing the next, I could make a mistake with the ball in hand.

There is no right answer to this question. It depends on the context – the state of the game, how confident you feel, how focused you are, and so on.

Either answer could be right – depending on the context.

Much like life.

It cannot be COVID

A close someone who works in a diagnostic lab in India shared a story of a father and a 30 or so year old son who walked into the lab recently.

The son was suffering from breathlessness. Everyone in the lab immediately suspected he was suffering from COVID-19 and suggested they test him immediately.

The father, however, had other ideas. Despite a doctor’s recommendation a week earlier to get a COVID test and X-rays, he decided to dither for an extra week. It cannot be COVID, right? Who knows if it is even real?

After folks in the lab insisted they proceed with a test, he reluctantly agreed.

The test confirmed everyone’s suspicions and the boy was finally rushed to a hospital.

Sadly, it came too late. He died a few hours later.

Then, there was another story from a family friend’s wedding. Even though they tried keeping to family only, someone showed up with a fever. They tested positive for COVID the next day.

A majority of the group then tested positive the following day.

But, somehow, when an elder in the family complained of fever and breathing trouble, they attributed it to something else.

Two days later, they finally took the elder to the hospital. She passed away within an hour of being admitted.

Sadly, I’ve heard many similar stories in the past months. They all involve one or more people in the family refusing to believe it could be a case of COVID-19. Their favorite politician told them not to worry after all.

I feel very bad for the families of these folks. It is a sad consequence of blind faith in leaders who lie about the dangers of what we’re facing for their own personal benefit.

Denying a physical reality is nearly always a bad idea.

The top priority test

You have made your list of five priorities for the day. There’s a simple question you can ask to make sure the order is right.

If the first task took significantly longer than you expected and you could complete no other task in the day, would you feel the day was successful?

If yes, proceed to priority 2. And so on.

High impact execution starts by getting the order of the priorities right.

Things are often not what they seem

A Netflix drama we’ve enjoyed watching over the years is “The Crown.” It does a nice job telling the story of the life of Queen Elizabeth.

There are a few lessons I’ve taken away from the show over the years. None, however, have hit home more often than the idea that things are often not what they seem.

The latest reminder of that idea was in a powerful episode that told the story of the aftermath of Prince Charles’ proposing to the late Princess Diana. The episodes starts with Diana’s delight at her good luck. She describes the proposal as the happiest moment of her life, celebrates it with her friends, and is giddy with excitement.

By the end of the episode, she begins to suspect that there’s little love in the marriage and begins to feel lonely and depressed.

The arc of the episode is beautiful. It is characteristically subtle and understated – a powerful example of great storytelling.

The lesson hits home as well.

Things are often not what they seem.

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: 

OverallThe IC PM RoleThe 4 key skillsRemote + Pandemic PM5 Decision Making frameworks/heuristicsProblem finding/solving with executives5 habits – high velocity product teamsGetting in – IGetting in – II

Skill #1 – Problem findingMost important skillProblem statement and hypothesisBuilding StrategyValidating problem statements and hypotheses

Skill #2 – Selling: Sales and MarketingWriting for executive audiences

Skill #3 – Problem SolvingRoadmapProduct specs

Skill #4 – Building effective teamsKnowing thyselfYour managerProduct 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

No alt text provided for this image

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.

No alt text provided for this image

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.

No alt text provided for this image

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.

No alt text provided for this image

(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.