David Hoang wades into the treacherous waters of the Should managers be technical? debate, and IMO comes out safely on the other side. I really like the 3 points he makes towards the end to articulate his point of view. I won’t spoil it because it’s worth reading the whole post. There’s one other bit I wanted to comment on, though:

The key roles of managers are to set expectations, ensure the team is operating efficiently, and maximize the output of the people on your team. In order to develop people, you must have a certain level of understanding of what skills are needed for people to be successful. However, as you progress in your career, there are going to be different org structures in place where it’s relevant. If you’re a Chief Product Officer, they likely have a more broad level of understanding of other functions outside of their domain and will put leaders in place who have the depth of knowledge in those areas.

I agree with the point that as you move into a leadership role, you can’t be as involved in the technical details of the product as much as you used to. But one mistake I see leaders make is to extract themselves completely from the product. And this becomes a bigger problem, especially in larger organizations. The further away the leadership team are from customers and the product, the more difficult it becomes to create product strategies that provide real customer (and business) value. Without the context of how the product works—and more importantly, how customers use the product—you cannot have a strategy that fully takes customer value into account. You end up with strategies that are too heavily skewed towards business value. A good product strategy balances both those things.1

So, leaders: Spend time with your product at a deep technical level. Download Postman and interact with the API. Ask to be invited to a few customer calls each week, and attend at least one every two weeks. Don’t lose your proximity to the heart that keeps your business alive and well.

1. Side note: last week I started a new series for the Elezea newsletter about how our team collaborated on developing our Product Strategy. I hope it will be helpful to those who need to do similar work in 2023. You can read Part 1 (and subscribe to get the rest) here. ↩

Via Chris Coyier I found this great post by Karl Sutt on How to communicate effectively as a developer. I especially appreciate him pointing out the importance of communicating clearly in short-form writing like Slack messages. His example of “low-resolution” vs. “high-resolution” writing in that context is a useful reminder for all of us:

In both cases, the example on the left is what I call “low-resolution writing”. There is very little context, too much reliance on pronouns and unclear references. The writing is not emphatic—the reader has to spend extra energy to work out what is being said. The examples on the right, on the other hand, try to make the reader do less work, even though it is more effort for the writer. The writer clearly has thought about how the message will be read.

This idea is similar to what Erin Meyer refers to as “high-context” vs. “low-context” communication in her (excellent) book The Culture Map: Breaking Through the Invisible Boundaries of Global Business. She explains in this HBR article:

I compare cultures along the Communicating scale by measuring the degree to which they are high- or low-context, a metric developed by the American anthropologist Edward Hall. In low-context cultures, good communication is precise, simple, explicit, and clear. Messages are understood at face value. Repetition is appreciated for purposes of clarification, as is putting messages in writing. In high-context cultures, communication is sophisticated, nuanced, and layered. Messages are often implied but not plainly stated. Less is put in writing, more is left open to interpretation, and understanding may depend on reading between the lines.

Choosing the right communication style for the right context is an important skill for everyone, but especially product (and other) leaders. If we assume too much context is known, people will misinterpret what we mean with our words.

I like Adam Thomas’s idea of identifying “survival metrics” at the start of a project. It’s a way to help teams stay grounded throughout the project and ask themselves whether they should stop the project, pivot in a different direction, or continue to invest in completing the project. From What Are Survival Metrics & How Do They Work?:

Survival metrics help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function to prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving permission to act quickly.

Adam goes on to discuss three questions that help teams identify those survival metrics.

Here’s a good analogy from Josephine Conneely to help figure out why growth might be stalling:

Imagine each of the 3 criteria pillars, Product, GTM and Org, as legs of a stool. Ideally each leg is of even height. This allows it to sturdily hold whatever is needed (in this case it’s increasing user volumes). Each leg can continue to grow (perhaps this is some sort of stool tree), and as long as the legs grow in tandem the success metrics of choice are safe. However, there may at times be an imbalance. Imagine an organisation with a great sales and marketing team who have created such demand that the product is struggling with performance issues as it scales to meet increased usage volumes. This leads to a lopsided stool, which while functioning, is not operating in manner which enables the org to capitalise on growth potential. If the product issues are not rectified, this could result in churn, reputational damage and a negative growth trajectory. Imbalance leads to lost opportunities.

Read the whole article for an illustration of the concept, and also how to use the framework in practice.

In Official myths Mandy Brown talks about how we are trying to solve the legitimate challenges of remote work by blindly (and incorrectly) assuming that the solution is going back to the office:

In many a remote-critical piece I’ve read, there’s a kind of mythical office that remote culture is being compared to, a place where everyone is welcomed, where collaboration and support is easy-going and automatic, where everyone is always whiteboarding or talking in the hallways. It’s kind of astonishing to see how much this presumed office utopia has become implicit, given we have literal decades of satire about offices as locales of poorly lit, soul-sucking, isolated work, where you are more likely to be abused by your boss than sponsored by them.

She goes on to explain the importance of supporting junior staff, and how office environments are often not ideal environments for that.

Tim Casasola’s post Create awareness of reality through bottom-up strategy points to an issue that we often see in teams—the work that they are doing is disconnected from the company’s core strategy:

There is often a difference between what an organization says its strategy is and what customer/project teams do on a day-to-day. When this dissonance is present, customer/project teams share with the org that their reality isn’t aligned with the organization’s vision. “It’s great that we want to pursue this new customer segment, but most of our engineers are focused on improving the experience of our current customer segment… and we’re far from where we want to be there.”

And yet, the org still says they have a “strategy.” The org turns a blind eye when customer/project teams describe their reality and relies on its existing narrative when feeling challenged.

The organization needs to be aware of when this dissonance takes place. So that they can learn from it, and come up with an actionable strategy.

Tim points to John Cutler’s “Bet Up” activity as a useful exercise to make this disconnect clear:

This seems like a really useful exercise for teams to undertake. It might also be really interesting to ask the executive team to fill out row 4 of the above, and see how their answers differ from what the teams come up with. Exposing a big strategy mismatch in such a clear way could be a really powerful tool to move the organization in a direction where a team’s day-to-day work is reflected in the overall product strategy.

Kate Clayton wrote an excellent essay on simplicity in design that goes way beyond the usual platitudes. From Be an Elegant Simplifier:

When I saw Danny Kahneman speak at a meeting last year, he shared a similar principle to the Crystal Goblet he took from psychologist Kurt Lewin, who, like Beatrice Warde, was active in the 1930s. Imagine, Lewin said, you have an object with forces pushing against it from opposite sides. Human nature would say if you want it to move one way, add more force to one side. But Lewin advised against this. A much stronger solution, Kahneman said, is to remove the force blocking the user’s way. Eliminate some of the muck.

This principle is very close to the product forces concept of Jobs-to-be-Done, and it’s great to see it framed from a slightly different perspective.

I love this sentiment from Rich Ziade in the post The New MVP: The Minimum Valuable Product. He talks about what happens when customers become a coalition that shares your mission. This is written from an agency perspective, but it applies just as much to product companies:

There is no more powerful political tool than releasing good software into people’s hands. You’ll find that the burden of consensus-building and campaigning is far lighter because the thing speaks for itself. It’s something you can draft behind to keep going.

Rinse and repeat. Done right and you’ll bank some political capital. You’ll need it along the way. Mistakes will be made and you will be blindsided by who-knows-what. Ideally you’ll string together a few wins that continuously impress people. Trust increases, anxiety decreases the temperature has gone down. What were once your customers will become part of your coalition, defending your product and mission because it is now their product and mission.

“…it is now their product and mission.” That is an excellent goal we can all aspire to.