This is a great hiring post on “reverse interviews”—or how to make interviews less one-sided and make sure you get the information you need to make a decision about a company. I like this question in particular:

Ask your direct manager for examples of promotions and attritions they have managed. Request stories about individuals they’ve managed in the past who have gone on to achieve significant success. Ask about the frequency of their meetings with direct reports, their perspective on their role in your work, their preferred communication styles, and their approach to staying informed. Also, clarify who makes which types of decisions.

This is a highly opinionated piece (nothing wrong with that!) and I think there’s some nuance needed, but in general I like these principles from How To Ship Fast. This one is definitely a hot take, but in a dream world where everything is perfect I would agree:

Time spent on prioritization is the canary in the coal mine for not being close enough to your customers. The discrete task of prioritization should take almost no time. Only work on Important things. Sort those Important things into “Do now” and “Do next”. If you are only working on Important things, the order does not matter too much (and don’t spend time debating it). If what’s Important is not obvious you are not close enough to your customers.

In his characteristic spicy way Marty Cagan says that if you want to replace product managers that’s fine—but be careful:

If you’re a CEO or GM, you might be thinking that instead of trying to recruit and develop strong, true product managers, maybe you’ll just do like Apple and skip the product managers, and you’ll just take responsibility for value and viability yourself?

If so, it’s critical to understand that the Apple product model depends on exceptionally strong product leaders. Many of Apple’s product leaders have 10–25 years of experience building world-class products at Apple.

In Lessons from going freemium: a decision that broke our business, Bobby Pinero (CEO of Equals) makes some interesting points about what they’ve learned about freemium pricing models. This point about how user friction is not always a bad thing stood out to me:

In all of our pursuit of getting people into the product, the thing we forgot is that the goal of onboarding is not for people to complete onboarding. It’s not to just get people into the product. The goal of onboarding is for people to get their first moments of value from your product. To get “activated.” And removing friction is actually detached from this goal.

Just like everything in product, this all depends. Every business is different. But it’s nice to see things from another perspective

I like this perspective from Ed Sim on recognizing that you can’t always build yourself into product-market fit…

There is no easy answer for a lack of customer traction, but my one suggestion before you commit to the idea that you are one feature away from success, is to go back to the basics and first ask if this is the right user or customer. If you believe you have that nailed, try multiple messages and keep learning from every interaction. You may have the right product today but for the wrong user. Or you simply may just have a cool technology in search of a problem to solve in which case you should start completely over.

I wholeheartedly endorse the RawSignal team’s take on performance reviews:

A great performance review is not an evaluation conversation, it’s an alignment conversation. It shouldn’t be a conversation about which things happened, it should be a conversation about which things matter. It’s an opportunity for you and your person to get onto the same page about where you’re seeing the work differently, because that is informative in terms of how the next year is going to feel.

Good advice here on when (and when not!) to hire the first product manager in a startup. This is also a good reminder to “let PMs be PMs”…

PMs are the strategy arm of this process, and should be empowered to own the roadmaps for how they’ll better the business, not just the execution of getting things built. In an ideal world, PMs will have better decision-making and execution than you within their domains due to focus and proximity to customer needs. This is how you scale. If you continue to hold all of the strategic decisions close to the vest and use PMs as glorified interns, you’re wasting all of the focus that they could be bringing to bear.

This is an older post from Lorin Hochstein but it’s new to me, and really insightful. It’s about how to best use our knowledge about the past behavior of a software system to figure out where we should invest our time to improve the system—and how the common method of error budgets is generally not a good way to do this:

I’m skeptical about relying on predefined metrics, such as reliability, for getting insight into the risks of the system that could lead to big incidents. Instead, I prefer to focus on signals, which are not predefined metrics but rather some kind of information that has caught your attention that suggests that there’s some aspect of your system that you should dig into a little more.

So basically, vibe-based incident analysis is where it’s at.

Good points here from Teresa Torres about deadline-driven development, especially the need to take change management slowly:

If your stakeholders are insisting you use date-based roadmaps, I wouldn’t engage in the ideological war about deadlines and predictable work. Instead, start with a feature-based roadmap. Give your stakeholders what they are asking for, and over time, you can introduce opportunities and outcomes.

Some great advice here on what to do when teams stop talking to each other. Starting with why it’s a big problem when that happens:

Teams that don’t talk to each other outside of transactional topics are barely teams at all. High-trust, high-engagement teams outperform, and those teams live and die on their ability to talk to each other. If that’s broken, your team is broken.