life – Jennie Ocken

Questions Before Answers

Usually on my desk, prominently displayed beneath my computer monitors, there is a bright purple index card with the words “Questions before Answers” written in my best fancy script. I have currently misplaced it and need to make a new one. I feel it’s absence.

After one particularly intense meeting with a stakeholder I walked away from my computer for a bit, breathed deeply, and created this card. Anyone who has worked with me is probably now thinking “I know exactly who she is talking about” but that’s the funny thing: you don’t. In every team I have worked with it’s a different difficult stakeholder, even varying day to day, often more than one. At this company it’s account managers, at that one it was operations, at this one here sales, over there engineering. I made the card because it’s a reminder of human nature more than a particular stakeholder. And in that conversation that day, it was me that needed the reminder.

Often in business we are trying to move fast. We come into a conversation, and someone is presenting something hurting them. Often, it’s something in the software that is not helping them. A missing filter, an interaction that isn’t quite right, a missing field, a process that is incomplete. Behind that is a whole set of business processes that have been built up by people doing their best with incomplete information or operations. People dealing with reality that we are trying to fit into software. Behind that is money, customers, demands. The real pain present, and all the things those people have done to solve their problem before talking to you, short circuits the conversation. We immediately get into solutions. “Just make this change”. Urgency drives and understanding falls by the wayside.

There are three things my kids know before anything else. The first is that I love them and they are safe. The second is that anything they want to do requires practice and there are no short cuts. The third is that we can solve any problem if we all agree first on the problem statement. Weirdly, all three of those also make it into my workplace. I’m at least very consistent. I am very diligent on how to bring those conversations back from “implement this change” to “how can we solve this problem together?”. How do I do that? The same way I do with my children.

The first thing I do is work to get down to the root problem. This includes questions like

Can you walk me through that in the application?
Please show me what you are doing when that happens.
Help me understand what you are doing, what are you trying to do here?
Explain it to me like I’m a German Shepherd.

That last one came from one of my favorite engineering teams, it’s great for breaking the tension.

Then I stop and I listen. I listen for a long time. I ask follow-up questions. I don’t try to solve their problem; I just keep coming back to make sure we on the same problem statement. The most powerful statements to help with this are:

What I hear you saying is:
I am seeing you do X, am I getting that right?
It seems like the current parameters are X, is that right? Where within that are you hitting a problem?

It is so easy to slip into “if we just change this one thing, it will solve their problem”. That is quick wins thinking. And when you can find a quick win like that, celebrate. Write about it. Post to LinkedIn. Take a pause and tell all your friends. Because those so rarely happen. If the problems we faced had easy solutions where would the fun in that be?

Only once I can clearly articulate their problem, by asking a lot of questions, do I start to offer any solutions. And this is the beauty of that bright purple index card. It’s a reminder to me to stay humble and curious. Fundamentally, that is what product is. It’s solving business problems with technology, but we can only do that if we truly understand those problems.

Note: I don’t use AI to help write my posts or create example pictures. I do use AI to create the header image. In this case I prompted both Gemini and ChatGPT by giving it my blog post. In this case ChatGPT won.

Early in my career, I moved into a new company as the only product leader for the engineering, network, and desktop support teams. I went from having 2 direct reports to (eventually as I rebuilt the team) 21 and department head responsibilities. Knowing I was going into a leadership position with a team that had had significant management turnover, I started with some small group and one on one meetings to get a sense of where the team was and what they needed. In one of these meetings, a senior engineering told me that I was there is “help us build things people want”. She was tired of building products that went unused and were then deemed a “failure”. The software was built right, the team was high performing, but the gap between what they were building and what the market was buying was enormous.

Throughout the companies I have worked at, teams I have led, and products I have built “build things people want” has continued to be my clarion call. It has wormed its way into conference talks and blogs. It has helped me find clarity in difficult conversations with sales and account teams. And it has become more nuanced and more complex as the challenges of building products has become more complicated. Who are the people we are building for? How do we know what they want? When do we drive based on instinct and when on user data? What kinds of experiments help us better answer these questions? What kind of commercialization is required? When do we trade-off between speed to market (I want it now) and performance and reliability (I want it dependable)?

Recently, I have found another phase slipping into my mouth more and more: “It Depends”. I have had to shed the comforting clarity that we are here to “build things people want” for the situational awareness, and yes anxiety, that there isn’t a clear right answer most of the time. What works with one company, customer base, team, market environment, or existing product and tech debt doesn’t easily translate to another. It is exciting to realize there is no rulebook but also terrifying that each moment is a rebuilding of the rules. Some things stay the same but the complexity, as it always was, is in the details.

As product managers it often feels like we spend a lot of time trying to find repeatable processes and the perfect document. While these things are valuable, it takes us away from those details and nuances. Perhaps it is simply my dislike of external structure, but I find myself wanting to explore that space of “it depends” more, while still holding on to that drive to “build things people want”. Because I do think there are mental models and, yes, structures that can help us navigate the ambiguity. But also, it’s work worth doing and maybe along the way of my own explorations I can help others untangle these knots. Also, I have been told by my teams before that they miss my “Jennie-isms” once we re no longer working together. So hopefully a little humor and interesting stories along the way as well.