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.