Not all product managers are created equal, and not all engineers are either! As a Product Manager, you won’t always have the choice of what engineers to work with. However who knows, one day you could be presented with the opportunity to pick a squad you'll work with. Even in your day to day interactions, as questions come up about work being done or the development team process, you’ll need to decide which engineer to approach with questions, request for consultation, etc.
These decisions will have significant impacts, not only on the quality of work your team produces, but also on the quality of your work experience as a whole. You spend a ton of time with the people you work with, make sure that you're having fun!
So assuming you are either in a position where you are interviewing engineers, deciding which engineers to work with, or just want to know what to look out for; here are three things I’ve found that separate the good engineers from the great.
I’d also like to note that I am purposely not talking about actual development skill set. This article assumes that engineers in consideration will have roughly equal coding abilities.
Flexibility to changing requirements
Change happens. It is one of the biggest differences between waterfall and agile methodologies. In agile software development, the Product Manager must constantly be in front of the customer and stakeholders in the organization. Both internal, as well as external factors can completely change the entire engineering team backlog.
External factors will always be present:
Think about what happened because of COVID. Imagine how many development team backlogs had to be adjusted based on the current state of the world. One example that comes to mind is AirBnB. Just like many other companies they needed to make both product feature changes, as well as personnel changes. Airbnb rolled out a significant amount of knowledge sharing to support hosts as they adjust during COVID. They also saw a complete change in how end users were booking stays with a significant shift to more rural locations. External factors should not be ignored!
Internal factors will also come up:
Business strategy will change. Depending on the size of your organization, knowledge and priorities can cascade down in different ways. Many organizations have adopted the OKR methodology, starting from the very top of the organization, and cascading priorities down. In this way everyone in the organization should be aligned to the highest level goals. That also means that when those high level goals need to adjust, everyone, down to your scrum team also needs to change.
New customer findings will drive change:
In an agile way of working, we should always be learning more about the customer. We shouldn’t be learning for the sake of learning; we need to act on those findings! If we are not adjusting our roadmap based on what we see, our team will not be successful. Understanding that this should be expected on the team is critical.
So change is constant. That means that the faster you can react to that change and pivot as needed, the better off you will be. Different engineers will have different levels of resistance or openness to change. Some will go right along, others will question why to better understand, others will complain the whole time, and some will basically refuse to adjust. Understanding where the different engineers you work with lie on this spectrum will be important to the success of your team.
2. Questioning the cut line
A cut line refers to the process of story mapping. Story mapping can be done at the overall backlog level or for an individual feature and its components.
At the backlog level, let’s say we run an ecommerce company and we currently serve the US. Canada is great too and we want to expand there. Using a story map, as a team we would flesh out all of the potential features (in this case most likely it would be all of the features we currently have in the US), and then draw a line that separates what we’ll go live with for our Minimum Viable Product, and what can wait until a later iteration. That is the cut line, a separation from what is in versus out for an iteration of work.
This can also be done at a feature level. Most of the time, a feature should be excluded from an iteration either because it is not valuable to the customer, OR because it is too costly to build from an engineering perspective. To understand the cost of a feature, you need to be able to partner with engineers who can quickly articulate that size.
In an ideal world, you’d have an engineering partner that can not only quickly and effectively size how difficult a specific feature or task would be, but also then think about the value it would drive to the customer. When a feature seems like it would take a lot of work, and doesn’t provide much value, having an engineer questioning that inclusion is key.
In a recent example, at Nordstrom we were working to launch a different experience when a customer adds a product to their cart from the product page. Design provided a cool line of copy that changes depending on the time of day, where the customer is, and other factors to surprise and delight people looking to checkout.
Unfortunately, we didn’t have all of the data on hand at implementation to meet all of those customer scenarios necessary to support this line of surprise and delight copy. Instead of blindly implementing like a machine. the engineer working on the feature reached out and mentioned how costly it would be to pipe that data through and accurately reflect the right line of copy to the right customer. While surprising and delighting customers is definitely important, we decided to hold off on adding that sub feature and instead move forward with an AB test to understand customer reaction to the overall change.
This is a small example, but over time these trade off conversations can make a huge difference. And if those conversations don’t happen, your team can deliver significantly less value.
3. Pragmatism
This has overlap with questioning the cut line, but goes a step further. One constant tradeoff that the scrum team has to make fairly consistently is whether or not to invest in component ownership / tech debt. This boils down to trust between the Product Manager and the engineering team.
Is the Product Manager open and understanding to the needs of the engineering team? Are they weighing the trade offs between taking on this tech debt and not doing it? And is the engineer who is proposing the work being pragmatic? Is this tech debt really necessary at this moment? The more the Product Manager can see their engineering partners asking these questions and truly proving the need to take on things like tech debt, the clearer trade off decisions will be to the Product Manager.
Pragmatism, questioning the cut line, and flexibility to changing requirements are all great things to have in an engineering partner. If you are fortunate enough to be able to select who you work with, or are involved in the interview process, make sure to dig into these commonly overlooked aspects of the job!
About the author:
Ben Staples has over 7 years of product management and product marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com
I do product management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Want even more book recommendations?! Contact me!