Helen Mou and Kevin Ochal share some good tips for remote teams in Making the Dream Work: Leading Distributed Product Teams. Most importantly, I agree that if you are deliberate about how you design your work process, it’s good for the whole team — whether they’re remote or not:

Instead of approaching distributed teamwork with the mindset of “we’re making it work, in spite of…” staying up late, working more hours, and spending more effort to be on a distributed team; we like to look at it as an investment in strength-building for your organization. Over time, this investment will build up your team’s trust battery, and create new habits, patterns, and behaviours that make any team — distributed or not — successful.

Related reading from me: Remote product management: challenges and opportunities.

Karolina Szczur makes some excellent points about using “technical debt” as an excuse for subpar products in The Technical Debt Myth:

Technical debt becomes a convenient blanket statement entailing frustrations, rushed decision-making, lack of process or architecture, and tedious maintenance tasks — the get-out-of-jail-free card for delivering a subpar experience.

It’s crucial to understand that as software and design grows older, that doesn’t necessarily mean we’re dealing with debt. We must look deeper under the surface to find the root cause of bottlenecks we’re facing. Only when we carefully assess the symptoms can we find solutions to building products that last.

While we’re on the topic, the most useful article I’ve read on technical debt is Henrik Kniberg’s Good and Bad Technical Debt (and how TDD helps) from way back in 2013. He discusses good debt, bad debt, and the importance of having a “debt ceiling”. Highly recommended post, and still very relevant.

Hiten Shah’s deep-dive into the history of Evernote is a very interesting read from a product management perspective. Of particular interest is the immense damage they inflicted on themselves due to a lack of focus on their core mission:

It’s hard to understate the damage that the branded products sold through the Evernote Market inflicted on the Evernote brand. It made absolutely no sense. Users didn’t want Evernote-branded tablet styluses or Evernote Moleskine notebooks or Evernote backpacks. They wanted an organizational and productivity product that worked.

The fact that the 2013 version of Evernote was widely considered the buggiest, most unstable version the company had released at that point added insult to injury. Rather than fixing the software problems that users actually cared about, Evernote started selling branded backpacks instead.

This is such a good example of the importance of knowing the core value of your product, and deepening that reach instead of trying to broaden into unrelated areas where you don’t have a core competency.

I’m a big fan of product discovery, and this extensive guide from Tim Herbig is a great resource:

The goal of this guide is to show you the extensive range a Product Discovery can have and how to set up and execute your own Product Discovery process. Which exact phases, tools, frameworks, and participants are needed depends on many individual aspects like the maturity of your product, which stakeholder environment you’re operating in, which resources you have at hand, etc.

I also like his definition a lot:

Product discovery is about ensuring that the right product gets built for the right audience. It’s the foundation for a successful implementation and launch phase later on and should give you the confidence to represent your product vision towards your team and stakeholders.

This is a guide I will return to again and again for inspiration.

The transcription of Cennydd Bowles’s talk on ethics in technology at SustainableUX 2019 is absolute gold and a must-read:

It’s a mistake to separate technical capabilities from human capabilities. These things act together. They become interwoven, hybridized actors. Things change what people can do and how they do it. It is true to an extent that old sage that guns don’t kill people; people do. But a gunman, the hybrid actor of a human and a technology coming together, sure as hell can.

So we have to abandon this belief that the things we build are just neutral tools. We have to recognize therefore that we can’t wash our hands of the social, ethical and political consequences of our work. This can be a tough sell to some. Technology and algorithms and then the bedrock of it all, data, are often seen as clean, objective, neutral things.

He gives lots of practical advice on how to make ethical thinking part of our work — including viewing ethics as just another design constraint, like any other. And for a more… uh… “incendiary” approach to this topic, also see Mike Monteiro’s We Built A Broken Internet. Now We Need To Burn It To The Ground.

Yana Welinder looks at different areas where PMs need to make sure we don’t let process get in the way of good product sense in her post Product Over Process. On the importance of making sure specs aren’t “set in stone”:

Focusing on product over process during the execution stage means constantly evaluating whether the product does what it’s intended to do. This requires PMs to see the product through the users’ eyes and, more importantly, to figure out ways to do user testing even when it’s hard. It also means that the build process needs to be iterative. If you discover that the product doesn’t have the impact you’d expected, you should change it before it reaches the users — even if that means delaying launch.

Jeremy Keith writes about the developer community’s need to always talk about new things in Dev perception. I think the same can be said for every other profession, including product management:

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The point he makes in his post is a very good one — that we should always evaluate any technology (or, in our case, methodology or framework) based on appropriateness, not newness. It reminds me of Kellan Elliott-McCrea’s excellent list of questions a team should answer before they decide to adopt a new technology in their software development process.

I always love a good persona case study, and The Story of Spotify Personas is no exception. But more than the story behind it, I am most interested in how teams use their personas (if at all). So I was happy to see the team devote some time to that towards the end of the article:

For instance, teams that want to create features from scratch can now choose their personas, map out the existing opportunities, pick a direction and start ideating from there. Although personas don’t replace user research, they can help us create educated hypotheses and save us time – meaning we don’t need to run foundational research every time we want to explore a new topic within the music listening experience. Our teams can now focus their resources on diving deeper into problems from the level set by the personas.

Equally, when teams are more focused on maintaining features, they can now map out their work and see how different personas would use it. They can create mental model diagrams for different personas and discover how they experience their journeys. And in doing so, they can refine the features to better fit certain ways of listening to music, whilst making sure they don’t alienate others.

I know I’m kind of in the minority here, but I am still a fan of personas—if they are based on actual research, and used to make better product decisions.