Katy Cowan’s interview with Frank Chimero is really great from start to finish, and covers so much ground on design and technology and how to think about our work. Frank’s view on the importance of not overworking yourself is refreshing, and we’ll hopefully continue to see more of this kind of thinking:

It’s really easy to think that not working full bore is somehow failing your teammates or that withholding effort is poor work ethic and moral weakness. That thought is worth interrogating, though, and it all seems kind of ridiculous once you get it out in the open. There should be no guilt for refusing to work hysterically.

Megan Quinn’s post on Development Cadence starts off really strong:

The hallmark of a well-run development engine is a development cadence that is brisk in bringing new products to market without burning out its builders.

And then it only gets better from there. Her point about being “flexible on scope, fixed on time” is spot on:

One way to establish a good development cadence is to commit to a predictable launch schedule and avoid slipping by pushing out features, not time. Some organizations commit to launching every month with the notion of ticks (small feature releases/fixes) and tocks (bigger, marketable moments).

There’s been a bunch of Evernote post-mortems, but I did enjoy the backstory and humor of A Unicorn Lost in the Valley, Evernote Blows Up the ‘Fail Fast’ Gospel. CEO Ian Small also makes a point about honesty and candor that’s really important for product managers to understand. He talks about how customers reacted when they finally came clean about the app’s quality issues:

Customers responded to his candor with a mix of optimism and skepticism, Mr. Small said. “The fact that we were able to tell the truth — that they already knew to be true — was a change of pace, not just for Evernote but for every tech-company relationship they probably have,” he said.

How we communicate when things go wrong lays your company’s soul bare. Hide behind “sorry for the inconvenience” and other fluffy language, and customers will lose trust. Be honest and show true empathy, and you’ll build stronger relationships.

I also really like this quote:

Now Mr. Small faces the challenge of recruiting engineers to fix Evernote’s “unique collection of bugs,” when they could be riding a bullet train to riches at a newer company. Hot start-ups can spend lavishly on engineering talent; they can always raise more if they’re growing quickly. Evernote has a different, more mature goal. It expects to reach positive cash flow this year, with annual revenue of nearly $100 million. “We used to be a movement,” Mr. Small said. “When we were a movement, we weren’t a business.”

Too many companies try to build “movements” instead of sustainable businesses that provide real value to customers.

👉 Also see Ahead of Its Time, Behind the Curve: Why Evernote Failed to Realize Its Potential.

Ulaize Hernandez Troyas makes a good argument for involving full teams in the prioritization of what to work on:

This type of ongoing communication throughout the prioritization process has a definite cost, but the number of benefits from this approach is worth it. We have reduced friction between teammates, which has saved us from long-winded conversations that stemmed from misunderstandings. The sense of ownership and purpose has increased the team’s motivation. On a more personal level, having these open product discussions has challenged my own thinking many times over, which has definitely improved our product direction as a result.

In terms of the specifics of how this works in practice, I tend to prefer a combined approach rather than asking the team to come up with an initial list of priorities themselves. We have a leads team that comes up with a proposal for our priorities for the quarter, based on our business goals and customer insights. We then spend about a week with the entire team discussing our proposal, refining the approach, and making sure everyone is aligned and excited about what we’re working on.

I really like Matthew Ström’s concept of Responsive Roadmaps that “visualize the process of turning uncertainty and complexity into outcomes and output.” He presents this as an antidote to all the things that are wrong with traditional roadmaps:

Traditional project roadmaps are right about our knowledge in a moment of time. They are good records of our beliefs about the correct sequence and magnitude of our work. But these roadmaps are wrong about the reality of work, and almost every roadmap I’ve ever used goes out the window as soon as the work starts. No battle plan ever survives contact with the enemy.

Responsive roadmaps are right about the nature of work: it is full of uncertainty and subject to change. They are wrong about what we’ll be doing in the future; the farther out we look, the less accurate a responsive roadmap is. That tradeoff affords us time to focus in the present on delivering at the highest level of quality.

He goes into much practical detail on how to create, maintain, and use responsive roadmaps.

I really like Jeff Gothelf’s approach to the question “Does every project need to be Agile?” in his newsletter issue Digital transformation is not innovation:

No. Every project does not have to be Agile. However, each project you work on should encourage and support agility. This means that every initiative creates the ability, desire and safety to change course in the face of evidence that contradicts our original plan.

He goes deeper on what it means for teams to have the ability, desire, and safety to change when needed.

I listen to The Product Experience podcast every week, so it was such a treat for me to be on the show this week to talk about Crazy Busy Product People. At first I didn’t know what to do — I’m so used to hearing Lily and Randy’s voices that it didn’t seem right to talk back, because that’s not how it usually works! But I did eventually find my feet (I think), and I’m overall pretty happy with how this turned out.

We spend most of our time discussing my article The dangerous rise of “crazy-busy” product managers, but we also touch on remote work and our 4-day work week experiment. I hope you can find some time to listen to the episode, and that you like it!