Guest Post by: Ralph Bautista (Mentee, Session 11, The Product Mentor) [Paired with Mentor, Chris Butler]
There are several ways to get into Product Management, the majority of folks stumble upon it by choice or because their organization needed to fill that role and you were the best candidate at the time. Either way, the role is relatively similar across the board. You are in a high impact role you could not get prior training to prepare you. Personally, I knew I wanted to be a Product Manager 2-3 years before I was finally given the opportunity. Helping our product director early on, I was exposed to really hard problems that required creative problem solving. And from then on, I wanted to learn more. I asked for more work product people usually handle, I read books about technology, about the role, purchased online courses and bootcamps — anything, to inform me what I was up against and what were the skills I need to get into the role and to excel when I got there.
These resources mentioned them. However, until you are knee deep in problems you are not sure how to solve, you just would not know what to do. Many things seem straight-forward on paper. It’s not until these problems are coming at you in waves do you, sit down and ask yourself, where do I start? When I was working on AET in the summer, I was misidentifying the feedback I was receiving as the core problems rather than the symptoms. As an inexperienced PM, it’s easy to fall into this way of thinking.
Instead of taking a step back to figure out if this is indeed the core problem or not. An example of this is when I once chose an easy solution for a bug case by hard coding the fix. Instead of understanding the connections. And identifying where the logic breaks down that is causing the symptom, I misidentified as the problem. As Mike Tyson once said, “Everyone has a plan until they get punched in the mouth.”
How I Exponentially Grew As A PM
The Product Group helps young product people develop ways to maximize their learning; during a time when a young product person is way outside of their comfort zone. Going through the early stages of being a PM with a mentor, have helped me get the most out of being outside my comfort zone, by introducing zone of proximal development. This is the difference between learning what I think I can teach myself, and what I learn when someone is helping me. This streamlines your learning and help you identify cues that facilitate your arrival to the correct solution. Our weekly meetings have become this, ‘steering the ship back to course’ maneuver as a weekly check for me.
Chris, my mentor for session 11, does this by asking questions in a way that makes me distill my thoughts further. I have learned to use the Thought Experiment and Randomness mental models daily, by adding adversarial thinking and unconventional constraints with my problem-solving process. Thought Experiments and Randomness are unconventional ways of looking at problems. They help with more focused thinking by forcing me to distill the problems down to constituent parts. This allowed me to look at a problem like a math equation and prioritize where to start and how to execute.
Mental models are tools for getting at what is most important as quickly as possible. Applying mental models, relevant frameworks, and techniques on my day to day helped develop the heuristics I needed to help me make an impact despite my relative newness to the team. These heuristics helped me get to the best decision I can make at the time, given the information I have. Thinking through problems for the users, while anticipating developer push back taught me to take a step back. This allows me to be proactive about the constraints engineers work with and the needs of the user incrementally until the requirements from both sides are met. Doing this enough times, develops an internal persona of understanding both perspectives and mitigating the back and forth. I am able to address concerns from both sides without the extra back and forth, thus saving valuable time you sometimes do not have. It’s a feedback loop to tell me if something needs a second look for course correction.
Attack The Problem, Don’t Wait For It To Come To You
Albert Einstein once said, “If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask… for once I know the proper question, I could solve the problem in less than five minutes.” Getting paired with a mentor to help me unpack how I perceive a problem and organize it into actionable items is the biggest value add The Product Group provides. The one lesson I learned that will forever have an impact on the rest of my journey, thanks to Session 11, is understanding what mental models to use when trying to define a problem well. Adding this to my process helped me identify all the signals from all the noise and facilitates my arrival at the best possible solution.
Especially for someone like me, who tends to get tunnel vision and see a problem super up close in, which puts me into an analysis paralysis holding pattern. For instance, when I was trying to define organizational KPIs. I was so focused on coming up with data sets I thought were clever. Instead, Chris changed the paradigm I was looking through by reframing my thoughts. We took a step back and identified the type of decisions the datasets precipitate.
Working backwards from the end goal helps parse out the noise. Without guidance, I would be a perpetual feel overwhelmed by the problem without a clear path to the solution. As a brand-new product manager, the hardest thing to do early on is making sense of all the things coming your way. A lot of these problems and things asked of us are not straight forward. Most of the time they are overwhelming and requires a developed instinct, that only comes from years of experience.
Mental models have helped slow down the game, so to speak. It has helped me see more of the chessboard through different lenses, than I was previously unable to comprehend and make sense of. Creating a problem solving funnel by defining the problem correctly, effectively provide a natural starting point. We recently talked about my next big project of revamping our student tools. I was stuck with many to-dos but no clear starting point. By defining the unknowns, ways to get to the answers through random constraints. Helped me focus on the user’s problem I am trying to solve and how to get those answers through user interview questions. The advice I received from one of our weekly meetings, helped me determine whom to speak with and laid out a path of where to go next.
The many different mental models, along with the guidance of what to use and when, have given me a step by step outline, not only for technical problem solving, but also problem solving through design. Mental models allow me to run the problem through the full gamut of my heuristics to mold and reshape my understanding of the problem. To break it into its constituent pieces and make them bite sized to be solved systematically and effectively.
A Process For Your Process
Chris often gives me Thought Experiments by giving me random constraints when I thought I have come up with the best solution. For example, when it came to providing feedback to my AET spec. He posed this question to me, “If the spec can only be one page, what would go on it?” This question allowed me to think of the essential problems that needed to be solved. It allowed me to step into adversarial thinking, and helped me put ego aside when reevaluating what I had written in the spec. After what seemed like endless iterations from the constraints provided by development. And thinking that I have finally cut out the fat and the nice-to-haves from my requirements.
The one pager constraint allowed me to reassess what is truly important, which is to get the tool made and put in front of my users. I shifted my paradigm from thinking of my spec as a trade-off conversation between myself and the senior developer for the tool, to what needs to be in this spec, to help my users as soon as possible. I was able to remove my biases and ego from the process. This adjustment helped and AET is finally in development. This form of higher order thinking, by simply understanding the trajectory and ripple effect of a decision, helped me scrutinizing micro and macro effects of my decisions. And for someone who is green in product management, I think it was integral to start here.
When I first started, I wasn’t exactly making bad decisions. I would say I was more trying to avoid making them. I feared failure to a paralyzing degree. I was apprehensive, fully knowing that a lot of things I was tasked to solve, fell into the “I don’t know, what I don’t know bucket.” And I knew deep down that less decisions, means less things I can be blamed for. I had so much happy to be here energy, I just didn’t want that to be taken away from me so soon.
By contouring our mental model discussions to my day to day, it provided this structured way of thinking. Approaching problems this way gave me a little bit more confidence to take the lead. And calibrated the decision-making tree in my head. It also fostered me to think deeply about the problems I am trying to solve and the solutions I am choosing to use. A simple mental “structure” gave me a little bit more room to think and be present in these moments.
Structures Help You Fail Forward
Because that is what we absolutely need as young Product Managers, structure and a lot of it. Structure in thought by helping us break down a problem systematically. Structure in steps and process that lead us to possible solutions. The Product Mentor program has provided me a silhouette of what a really great product person should look and think like. The way I was put into situations to really, truly understand the problems I am trying to solve, by applying just the right amount of pressure at the appropriate time; helped me get to the right solution the right way by using frameworks, mental models, artifacts, that only hint in the right direction, leading us to the water, we still have to take the drink, so to speak.
Those blanks are filled with the answers to the questions Chris prompts me to think about. Not too long ago, I was in a state of, “I don’t know, what I don’t know.” These meetings have provided me with so much insights, that I now “I know what I don’t know.” I hope to use the rest of the program to turn another corner and finally, “Know what I know.” And hopefully I can tap into this exponential growth and development, not only as a product manager, but as a product leader in the industry. By making sure I follow a similar process of using different mental models when evaluating problems and coax the best possible solution to present itself to me. And falling back on the valuable lessons from Session 11. Then repeating the same approach moving forward.
About Ralph Bautista
Just a California kid in NYC. First year product manager iterating on an external and internal tool. Currently teaching myself front end development to be a better product manager.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 