In a recent interview, a person with over 20 years of experience in delivery told me he wished to move into product. He was confident his delivery experience would be enough to get him into product management. After all, his communication was top-notch, he could connect with people, write user stories, and explain things to developers. So, what was stopping him? Three simple questions (below) that I typically ask people when interviewing for product roles.
1. How did you manage conflicting priorities? If the person talks only about stakeholders and negotiating with them, it’s a clear giveaway that the person is not a product person. A product person would prioritize outcomes and use that to negotiate with stakeholders.
2: Do you know why this project/product was initiated? This is my favorite. A delivery person, if truthful, would say that they didn't initiate the project and possibly give tactical answers. For example, the interviewee mentioned that the project was initiated by someone before him and involved migrating from .NET 3.5 to .NET 4.0. But why? Then I would ask who the sponsor is. Next, what problems were they trying to solve? By now, a delivery person would not be able to answer coherently. A product person, however, would know the “why,” not just the “what.” In fact, they would likely know the business benefits in terms of $ figures like the back of their hands. Product management is not about features or user stories. It’s about solving problems and building something that customers love, while adding value to the business.
3: Did you measure the success of your program? Or, what, in your opinion, constitutes success in your program? (Note: I have shifted away from product terminology, as pure product work in a services organization is often limited, so people typically have program management or delivery management experience.) In this case, the person mentioned being on time and within budget. That was the last nail in the proverbial coffin. A product person doesn't measure success based on budget and schedule. They measure success based on impact or outcomes. For example, in the above .NET migration program, had the person measured the impact of security incidents and support costs before migration and then articulated clearly that post migration there was a reduction in security incidents and support costs –– my response would be: “Now we are talking!”
While every role –– sales, delivery, product –– commands due respect, when considering a transition from delivery to product, begin by thinking like a product manager. Start applying product thinking in your role. Do these three simple things:
Find out why you are doing this project/program. Get a business case done (it’s fine if nobody sees it; at least you'll know why you're part of this project).
Look at scope fluidly — not in terms of features, but outcomes. And don't think “plan,” think “roadmap,” clearly articulating and prioritizing based on outcomes.
Measure success by the outcome delivered (cost reduction, user count increase, churn reduction, etc.), not based on meeting budgets and timelines.
Here’s hoping to see a lot more managers move from delivery to product – so do reach out in case you need help applying product thinking to your projects.