I enjoyed this interview with Todd Curtis, Chief Product Officer at You Need a Budget. They cover a lot of ground in From spreadsheet to digital product: You Need a Budget’s Product Excellence evolution, but I especially like the discussion about the many different customer touchpoints they maintain:

As ideas move into discovery and validation, Todd and his team go to customers directly. Todd tries to have hour-long sessions with two customers every week to learn about their budgeting story. Through the company’s frequent online workshops, YNAB is able to engage with hundreds of customers each day and hear their questions and concerns.

All these efforts help YNAB gain a deep understanding of what their customers really need and informs product strategy with actionable intelligence.

The use of workshops (or in our case, webinars) to engage and get feedback from customers is a great practice. It provides tons of value to customers while also helping companies to understand their needs better.

Ted Bauer and Michael Boykin take on daily, synchronous standups in their article The Daily Standup is Broken, What Should You Do Now?

Asynchronous daily standups or check-ins help to put an end to boundless, traditional standup meetings and get the whole team on the same page with fewer meetings. And corresponding written status updates within a team coordination tool or platform — something that allows every team member to share and review updates from today, yesterday, or even last week — allow everyone to consume updates easily and on their own time.

We landed in a similar (asynchronous) place with our standups, and I wrote about it a while back in Useful daily standup meetings for remote teams:

The issue is always the same: How do we have standups that are useful and that don’t feel like busywork that just takes us away from the jobs we’re supposed to be doing? By using an asynchronous bot and adapting the questions to our needs, we accomplished a few important things:

• Every member on the team takes a few minutes every morning to plan out their day, and troubleshoot anything that might have gone wrong the previous day.
• Instead of weekly meetings of an hour long where we discuss what everyone’s working on, we now have focused 30-minute meetings every Monday where we solve problems and discuss issues that came up during the week.
• I am much more equipped to fulfill my role as Product Manager because our updates are more frequent and the signal to noise ratio is extremely high.

Matt LeMay’s post on how to build safety into team communication might not immediately seem that relevant to product management, but Why is Psychological Safety at Odds With the way we Work? is an excellent reminder for all of us:

Now let’s talk about the product managers who are willing to take on the individual risk that comes with creating psychological safety for their teams. These product leaders often don’t have the opportunity to step into those big “visionary” roles – not because they lack vision, but because they are so busy doing the emotional labor of cleaning up after the other product leaders who are making those big, lofty promises. These are the product leaders who earn the trust and respect of their teams by helping leadership understand the real-world trade-offs that go into actually delivering products, even when leadership doesn’t want to hear about it. And here’s the thing: over time, they actually train company leadership to be better! They sharpen their organization’s focus by saying, “You can have this OR you can have that. Which is more important given our goals and constraints?” These product leaders deliver so much value to the companies they work for, and the truth is, they don’t always get rewarded for it.

Over the years I have become more and more convinced that team safety is the most important job a product manager has.

Paul Ford’s Carrot Centralization is a great plea for the importance of user research, but I think he also inadvertently came up with an excellent definition for product management:

You might think our job is to build software but just as often it’s to help you avoid building the wrong software. And when you build, build carrots.

Because, as he says earlier in the post:

Carrots work. Sticks don’t. Computers can’t make people do things. They have to want to do things.

Sachin Rekhi reviews April Dunford’s book Obviously Awesome: How to Nail Product Positioning so Customers Get It, Buy It, Love It in his post Positioning for Product Managers:

While 2000’s Differentiate or Die spoke at length on why positioning is important, it never really went into detail on how to actually go about developing your product’s positioning. The traditional approach is to develop a positioning statement. While useful as an output to your positioning process, it really doesn’t describe the process one could use to come up with such a positioning statement. That’s why I was excited to read April Dunford’s new book entitled Obviously Awesome, which is an in-depth tactical guide on how to go about actually developing your product’s positioning.

The reality when it comes to positioning is that most companies end up with default positioning. This is simply leveraging the positioning that the original folks who came up with the product concept thought about when they conceptualized the product offering. But what’s important is to be deliberate about your product’s positioning because a great product could end up failing due to poor positioning alone.

He also discusses April’s advice to replace a “positioning statement” with a deeper 5-part positioning framework which defines the following for your product. This is a really good summary of the book.

In Getting to the Heart of Digital Accessibility Carie Fisher makes a compelling argument for making accessibility a priority in tech companies. Her conclusion really resonated with me:

Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

She mainly mentions developers in this article, but I’d argue that it is very much also the responsibility of product managers to make sure accessibility is always in the discussion on projects. We need to make sure that if extra time is needed for accessibility, we build that into the planning.

Further reading

For some practical advice on how to make emails more accessible, see Accessibility vs. Inclusion: What it Takes to Create More Inclusive Email Marketing Experiences and Email Accessibility: Looks aren’t everything.

For an example of how not to approach this topic, see Should websites be accessible to everyone? Domino’s says no.

In his post Why Feature FOMO Stalls Product Innovation Brian Crofts discusses the many reasons why product teams tend to add a slew unnecessary features to a product. This issue hit close to home:

Pendo’s recent State of Product Leadership survey found that 77% of product teams are evaluated based on the number of features they ship. This gives product teams an implied incentive to add more, regardless of whether those features are being used and adopted.

I can only trust that this has changed by now, but when I worked at eBay product managers were measured by how many PRDs they wrote. The things didn’t even have to ship. The measure was literally “How many Word templates did you fill out this quarter?”

Instead, Brian proposes a better way:

Technology brands should hold their product teams accountable for metrics that have the greatest impact on success. Instead of the raw number of features shipped or revenue driven, metrics such as feature adoption, customer happiness, and customer engagement are critical. These measures point to which features are working now and help form longer-term rollout strategy.