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.

I’ve always been adamant that Product and Engineering are in a partnership, not a “healthy tension” relationship. So I very much agree with this post:

The problem is in the assumption that Product and Engineering teams inherently have different goals. They don’t. Both teams are responsible for the growth and stability of the company, for revenue and scalability. Neither can succeed without the other. When we assume otherwise, we sell each side short.

How to Scale Yourself Down has some really interesting advice on how to go from leading a team at a bigger company to rolling up your sleeves at a startup. A couple of my favorite quotes:

Avoid process out of practice. Leaders who are successful in a startup are the ones who naturally reinvent their own toolboxes, and question what the process is trying to accomplish before establishing something that might be too heavyweight.

However, process is a double-sided coin. “There’s often an overcorrection when leaders move from big companies to small startups. Folks want to shake off that big company feeling and run hard in the other direction. And while the idea of no process sounds fantastic, issues emerge if you don’t start adding at least a little bit of it early on,” he says.

And:

To me, a well-made decision is one that you can explain how and why it was made. Ingraining this in the culture early on will support transparency as the company grows, promote consistency, and reduce politics. In essence, ‘don’t blame me, blame the framework’.

I didn’t realize that there’s a strategy backlash going on in some corners of the internet, but Packy McCormick has a good defense of the importance of having a good strategy:

Execution without strategy is wasteful and tragic. Just as “Companies that have the best products, most talented people, and fastest growth are precisely the ones for which moats are most important,” companies that are the best at execution are precisely the ones for which strategy is most important. They’re the only ones that have a shot. The better you are at execution, the faster you can run in any direction. A good strategy helps you run fast in the right direction.

He also provides a good summary definition of what strategy is, based on the (must-read!) book Good Strategy Bad Strategy: The Difference and Why It Matters:

A strategy is a high-level plan to achieve one or more goals under conditions of uncertainty, designed through recognizing the challenge (diagnosis), setting a direction to overcome it (guiding policy), and detailing steps to implement the policy (coherent actions).

The biggest problem I’ve seen in organizations that struggle with good strategy is that everyone wants a strategy but it’s very hard to figure out how to get started with its creation. It is such a lofty, nebulous concept, and everyone has a different idea of how to go about it. So it’s really important to define what it is and what it’s for, and get broad agreement on that, before starting to create a strategy. To put it another way, make sure you define the black hole words.

For more on this, check out my (very long) case study on Collaborative Product Strategy Development.