I don’t know about you, but I always hated those questions in school that would begin with ‘why?’ or ‘can you explain...’ I always thought to myself, why do I have to explain myself? I know the answer. Those questions are one of the main reasons why I leaned towards math at a young age. 2+2 = 4… no questions asked.. It just is. Let’s move on and focus on the important stuff.
As I started my career, I learned just how important ‘why’ and ‘explain’ are in the real world. As a Product Manager, I had 10+ people a day coming to me across the organization, acting as if the building was burning down. We needed to build a feature, address this customer issue, or change our roadmap. At first, I wanted to help everyone as much as I could and went with it. A few months into my first PM role, I realized that most of the questions and asks people were coming to me with really weren’t that important or were simply wrong (in the case of the feature that needed to be built, as an example). So, I started asking why? And then I would get a response and ask why again. By the third ‘why’ people usually broke down and said OK, it’s not that important, or we don’t need to build the entire feature.
As a Product Manager, you have finite resources: your time, engineers, designers, and more. You should be smart about how you leverage your resources and aim to have the highest output, whether it be aligned with revenue or customer impact. There are many important PM traits, but being comfortable pushing back and asking why ranks near the top of my list these days. When I started my first PM job, my VP of Product told me ‘You have finite resources. The best Product Managers find a way to leverage the resources they have for the most impact, not complain and ask for more resources.’ Whenever I reflect or spend time thinking about strategy, I always come back to that line.
It Doesn’t Come Naturally
Early career PMs and founders (I have experience in both) always jump the gun and want to do everything to impress their boss, get their first customer, or just make people happy. I became good at asking ‘why’ as a PM, but I hit reset when I became a founder. We didn’t have anything; we didn’t know anything. So, we took everything we heard from users and potential users and took it at surface level. We were so happy that they’d even bother talking to us, let alone try our product that we didn’t want to question them. Unfortunately, we started doing that too much and it was taking us in a million different directions. I took a step back and decided to be the ‘bad guy.’ My other co-founders and people within the company would come to me saying they got feedback that we need to build this feature, and I’d ask why? They said because they wanted it? I asked why again… ultimately, they would get flustered because I was never ‘sold’ that we needed to build that feature or change the color of the button. This behavior was typical while I was a Product Manager. Everyone wants what is best for their customer or their team. It’s your job as a Product Manager to determine what is best for your product, the business, and the company. Some people are naturally good at this, but most people need some practice and though I hate to say it, even the experience of being burned a little in order to learn.
Customer Interviews (Discovery)
When you’re doing a customer interview and someone tells you they have a problem, ask them why they have that problem. Then, when they give you a response, ask them why they haven’t tried to solve it yet or why the current solution isn’t solving it. One of the critical things here is understanding how vital or painful that problem is for the customer. Remember, you have finite resources, you don’t want to spend them on something that annoys your user, but they deal with it. You want to make sure the pain you’re addressing is not only in that customer’s top three problems, but also for five or ten other customers too. Too often, as Product Managers, you hear that a customer has a problem, and you’re excited to go and solve that (it’s natural). Then, you spend all the effort with UX to design it, engineering to implement it, marketing and sales to promote it, and no one uses it or cares. It’s most likely because it wasn’t that big of a pain point, and you didn’t do enough to vet it.
If you focus on the why and ask the customer/user to explain, you’ll truly understand how big of a pain point it is and why it’s a pain for them. They’ll also tell you how to solve it at the surface level (e.g., a feature request), but if you dig deeper and understand the problem by asking why, you’ll build a better solution than the feature they initially requested. This way, you can make an informed decision on whether or not you should proceed, and if you do, you have a better sense of direction and can tell your engineering team and other teams why you’re pushing for resources because they’ll ask why too!
Feature Requests
Depending on what type of product you’re working on (e.g., B2B, B2C, marketplace, etc.), you’re going to get feature requests from different sources. Most of my experience as a Product Manager (and founder) is on the B2B side. I had feature requests from sales, customers, customer success, support, legal, go-to-market, engineering, and other Product Managers. Every quarter my team and I went to the ‘sources’ to gather feature requests across the business. It would take 2-3 weeks just to gather and understand the feature requests.
When you have this amount of input, everyone is fighting. Support is getting yelled at by customers because we don’t have feature X or it doesn’t work ‘right.’ Sales folks are knocking on your door so they can close more deals, go-to-market is asking you to build features to support new markets, engineering is asking for bandwidth to address technical debt, the list is never-ending. How do you understand what’s truly important?
Tell the requester to explain, rather than send you a one-liner and then start asking why. Why does this customer need this feature? Why don’t they implement it in this way? Why hasn’t competitor X built it? Why do we need to burn down technical debt?
Another great question is, what if we don’t build it? What would you do? You’ll learn so much from the response. Are you going to lose the deal? Or will the customer just implement it differently? Is the backend going to tip over, or will we just be getting some failures that impact a small percentage of customers? Once you understand why the request is important, understand what would happen if you didn’t do anything. Knowing what would happen otherwise puts everything into perspective and helps you build your roadmap.
Conviction
All of this work of asking why and asking the individual(s) to explain themselves is for you to build conviction. The conviction that this thing (feature request, bug, product, etc.) is worth spending your finite resources on. When you bring it to the table (your boss, executives, engineering leads, etc.), they’re going to ask you the same questions. Your VP of Product will ask you why you’re spending 80% of engineering resources on technical debt for the next two quarters. If you don’t understand why and have no conviction around it, you’re going to be in for a not so fun conversation. The more conviction you have (by asking why), the less push-back you’re going to receive. You are on the front lines. You (should) know the customer and the problem better than anyone else in the room. You just need to build the conviction and show it.
Rejection
You won’t be able to build everything you want to build. It’s hard to swallow that, especially for new Product Managers and founders. When you do ‘reject’ someone, be it a salesperson, a customer, a support team, or another PM, have your reasons why. Early in my career, I was always worried about telling people no, or we can’t do it right now. When I started having those hard conversations and explaining why we’re not building that feature or spending our resources there, people were pretty receptive. Once you build that conviction and know why you are or are not doing something, make sure to tell others your decision and the why behind that decision.
You’d be surprised if you tell someone no, but instead share that we’re doing X, just how excited they may get. ‘Wow! I didn’t even know that was being considered, I’m thrilled that’s getting built’ was a typical response I received when presenting our roadmap and the why behind it.
Parting Thoughts
Asking why is not easy. At first, individuals might be turned off by the fact you’re trying to dig deeper. They may think that you don’t trust them. A good rule of thumb is to explain why you’re asking ‘why’ (ha, get it?). I’ve tried to preface the conversation with something like ‘Anne, I’m very interested in the problem you’re facing, and I want to understand the root of the problem so my team can best help. I’m going to ask several questions and keep digging, so be ready!’.
Ultimately, those questions in grade school that made us (well, maybe just me) mad helped us so much more than I realized in the real world. Ask why, ask the individual(s) to explain themselves, and build as much conviction around the problem/bug/feature request as possible.
Like what you just read? Drop me your email and receive updates when I post new content!