Product Collective - Keep your product team healthy

Use product retrospectives to keep up healthy teamwork

It’s healthy for the members of a product team to have different ideas on how to approach their work. But it can quickly become unhealthy if that team doesn’t take time occasionally to pause and discuss how things are going and what changes they’d like to make. That’s where product retrospectives come in. Here are some suggestions on how to lead a retrospective so that you can keep your team working together in a healthy manner.

NEW TO THIS NEWSLETTER AND LIKE WHAT YOU SEE?

Left untouched or without the right analytics solution, the data your application generates provides little value to you. But, when combined with analytics, it delivers endless insights and opportunities for your end users. The Hitchhikers Guide to Embedded Analytics can help!

11 Ways to improve your retrospectives. A retrospective is a meeting held for the purpose of reflecting on the product development or workflow process. The aim of a retrospective is to look closely at the processes and products produced during a sprint, discuss these as a team, and decide on a way forward together to drive constant improvement. Joanne Perold shares 11 top tips to make your retros successful.

(via @agile42)

How to lead a product retrospective. A product marketer’s job doesn't stop when a product is out the door, but product marketing teams do tend to be very launch-focused. These launches provide a great cadence for product marketing teams and can be a good frequency for product retrospectives. Jeffrey Vocell provides some guidance for leading a product retrospective that applies to product marketers, or any product person who wants to reflect on their product development work and find opportunities for improvement.

(via @PMMalliance)

Continues below...

What's in a name?

Today marks a pretty historic day in Cleveland, Ohio. The Cleveland Indians Baseball Club -- a professional baseball club that has fielded a team dating back to 1894 in what was then called the Western League. For those not paying attention to the world of pro baseball, this isn’t another example of an owner uprooting a professional sports franchise and taking it elsewhere. (As a native Clevelander, not having a pro football team during most of my high school years is still a bit too raw for me). It’s essentially a re-brand. The new name: The Cleveland Guardians.

This major re-brand got me thinking about when it may be the right time to consider a brand change for our products. 

If your mind immediately goes to the place of, “That’s for the marketing team to figure out…”, you may want to re-think that. These days, brand isn’t just a function of marketing. Just like baseball, branding is more of a team sport and you, as the product person, ought to play a role in the process… especially with something as important as a complete re-brand. 

But when do you know it’s time for a major change for your company or product’s brand? There are a couple of things to look out for:

1. Your brand no longer reflects your core mission. One very recent example is the change from Facebook to Meta. As I’ve written about before, Facebook, er, Meta… well, they’re all-in on the concept of the Metaverse. And their new multi-billion-dollar name change now reflects this.
    
2. The features you’ve added have transformed your product into something new altogether.  Sometimes, new features are just that. But sometimes -- it changes the product so dramatically that it has to be a brand new thing. Dunkin’s change (from Dunkin Donuts) was a reflection of its addition of so many offerings that were well beyond donuts -- from espresso to sandwiches and even whole bean coffee.

When considering a re-brand, don’t let your lack of knowledge or experience be a reason that you take a backseat in the process. Brush up and learn some new things. Work with your marketing team to help. Just remember, these are your products to manage -- you should be a part of the process, too. 

Data-Informed Retrospectives. One of the key steps in running an effective retrospective is gathering data. Unfortunately many product teams either err in spending too little or too much time collecting data. If they don’t spend enough time, they lack vital information to reflect on. If they spend too much time, they have little capacity to analyze the data and come to conclusions on how to best improve as a team. The folks at Age of Product explain how you can avoid falling victim to both scenarios by gathering data for your retrospective continuously and asynchronously.

(via @ageofproduct)

Remote retrospectives: 11 Tips for leading retros remotely.  Retrospectives can be an incredibly helpful tool, giving teams an opportunity to bond, learn, and grow together. But as anyone who has participated in a less-than-productive retrospective can attest, not all retrospectives are created equal. Engaging in a healthy, open discussion about what went well, what didn’t, and how to improve next time, can be tricky. Doing it remotely (as many teams have learned in the past year) adds another layer of challenges. Alex Glabman shares 11 tips for running an effective retrospective when everyone is somewhere else.

(via @planview)

The blame game retrospective. Retrospectives can be a powerful tool for adjusting your product team’s approaches, but they can also be detrimental to your team’s effectiveness. Stefan Wolpers describes one scenario where retrospectives become counter-productive that he refers to as the “blame game retrospective”.

(via @StefanW)

The proliferation of services available as an API offers an incredible opportunity for engineering leaders to carefully evaluate what their teams build from scratch and what they build on top of. It’s no longer a "build versus buy" decision. Development teams have a range of options these days and need to be asking, "How can we build better — and how can we build faster?"

In the API economy, we can free up developer time to focus on building what is truly strategic and buy the components to assemble the rest. Engineers are the gold resources. Your developers’ time is directly correlated with ROI, and how you allocate their time is critical. Yes, developers need to build, but they don’t have to build it all.

Join Shailesh Nalawadi, Head of Product for Sendbird, to learn how product leaders can help free up developer time to focus their time and energy building what matters the most. We'll be covering important questions — but will make plenty of time to answer your questions as well!

• Fullscript
• Anywhere

• The Home Depot
• Atlanta, GA, USA

• The Home Depot
• Atlanta, GA, USA

• The Home Depot
• Anywhere

• The Home Depot
• Anywhere

• The Home Depot
• Anywhere