Finalize Your Product Management Checklist

Rover CTO on Product Management (Part 3)

We’re halfway through the 14-point checklist! As I mentioned before, there’s nothing wrong with leaving a few boxes unchecked. Depending on the feature you’re looking at, product management teams will have to determine the level of detail required. In other words, these points are useful as singular and collective guides for focusing on what’s most important for a new feature.

Let’s continue to go through the last seven points to consider for your next big project.

Question 8: Does the change require cross-team coordination?

• This may seem obvious, but product management teams often do not get on the same page. If a project requires two or more teams, you’ll need to map out everyone’s responsibilities. For example, we have 17 engineering teams at Rover. As you can imagine, big projects require everyone to align before you start ramping up activities.

Question 9: Is the change being rushed or urgently required?

• This is the first sign that a new feature is not going to be well thought out. Instead, you create situations where rushing to solve one problem leads to generating additional issues. Sometimes, we need to pause and thoroughly think about how to correctly solve a problem. Urgency must be set aside to do things right.

Question 10: Does the change seem easy because you’re “dusting off” old code?

• Simply put, there’s no such thing as “old code.” Even if a specific process worked well in a previous application, you need to approach every new project from square one. It’s easy to think that you can repurpose something that works well. However, this usually causes more problems than it solves. Just remember, code doesn’t get dusty in a computer!

Question 11: Will the change create “hard to see” errors?

• Tracking issues with changes to visual interfaces (website, mobile app) are normally easy to find. For example, you can see right away if a new video isn’t loading correctly on your website. However, if you’re making changes on the backend to algorithms, issues associated with these changes may not be as obvious. As a result, it’s important to map out issues to look for when making changes.

Question 12: Are many people dependent on the system or data that has changed?

• With any new change, it’s important to prevent confusion within your organization. For example, you can make a change to a data field and now exactly what’s going on. However, if another department isn’t aware of the change or thinks it’s affecting another process, confusion will arise quickly. Before you make any sweeping changes, you need to ensure that all users are a part of the conversation.

Question 13: Do stakeholders have competing requirements for a change?

• Rover uses a sitter scorecard for dog walkers. However, two teams thought about its benefits on completely different terms. Our customer success team wanted the scorecard to provide coaching on how to improve. On the other hand, the marketplace team wanted the scorecard to show how a sitter was being rated to provide incentives for better performance.  So, instead of launching efficiently, we got into a tug of war and the project was delayed. In the end, you want to create alignment ahead of time to prevent a mediocre product that winds up somewhere “in the middle.”

Question 14: Does the change require peer feedback to help figure out what to do?

• When thinking through a new feature, our product management usually comes up with three scenarios. Sometimes, it’s difficult to figure out which direction is best for the project. At Rover, we share these scenarios in an open document that is accessible to the entire group for input. This process enables feedback to come in from a wide audience that goes beyond your immediate circle. As a result, you’re able to make better-informed decisions that capture a wide range of input across the team.

Click here for Part 1

Click here for Part 2