A Career in Product Management Taught Me All I Need to Know About Wilderness Survival
A few months ago, I was standing in a fast-moving mountain stream with my five-year-old son and our dog. We were simply playing around — and I looked up ahead and saw some small rapids. I began thinking: “What would happen if this were a raging river, and I fell in somewhere? What would my first actions/thoughts be? How would I handle it?”
First , I would look for a large enough branch to grab onto from either bank. If one didn’t present itself, I would then try rolling onto my back to see if I could ride down flat and formulate a next step. I would stay calm enough to wait for a large branch, rock or calmer area of water to wade into. I would think about the amount of clothes I had on, and if I were wearing a backpack or a large jacket that should be stripped off, etc.
Instead of freaking out about the current situation, I would look ahead as far as I could to see what objects or tools were approaching that I could somehow leverage. I would be certain to look ahead to ensure I knew where I was going, and whether more problems (waterfalls) weren’t approaching. I would try small iterative efforts to meet my goal (of staying alive).
As I was daydreaming, an odd thing occurred to me. I sensed that the way I processed catastrophic danger was totally different than I would have 7+ years ago (pre-product)! It was more structured and intelligent than I would ever give myself credit for (or anyone who has known me for a long time would either).
I was noticing a different thought pattern from being a PM, a total paradigm shift in my problem-solving mental model. The old Eric would have panicked and rushed to try brute strength or attempt something based purely on his own physicality. He would have not tried to understand the true problem, but would have gone to solutions too fast. He would have placed so much emphasis on gut reactions and overused his intuition. He would not have remained calm; his heart rate would have been jacked; and I am positive he would have swallowed large amounts of water in his panicked state. He would have had one idea and stuck with it; if that didn’t work, he would have tapped out.
So, what do I have in my tool kit now that’s so special from being a PM for more than five years? Experimentation, discovery, failure, creativity and iteration.
Product management prepared me for falling into a raging river.
As I have grown in product, I’ve gotten comfortable with formulating 2–3 approaches to solving problems, instead of impulsively jumping right to a solution, and bringing rushed features and use cases to dev teams. I try to understand the river, the river banks, the depth of the water, the temperature of the water. Are there people on either side of the river that can help me? Is there some sort of pattern to this current I can figure out, which I could leverage in my quest. I want to know the screen resolution and the thickness of rubber gloves the factory worker is using on our software — the real problems and real goals. I would have spent time understanding how rivers function, and doing lots of research on river survival studies and what experts have to say.
I have worked in other industries, where problems boil down to, “There is one right way to do this, and if that doesn’t work, then call general counsel.” There is nothing wrong with that way of approaching problems, but it’s a different type of mindset than software development requires.
In software development, there are 57,000 ways to approach any problem, and it’s up to the product manager, UX designers and engineering team to figure out which one is the right one, at the right time. There are also 57,000 ways to trim down the “Minimum Viable Product” of your product. As a PM, you get good at honing in on what features can be trimmed off of your product MVP while still solving the problems for your users. You are thinking critically all the time, and weighing many different combinations of options. This requires a forensic understanding of the use cases and problems you are trying to solve, and a deep understanding of “how will we know when we get there.”
Earlier in my product career, I was guilty of making narrowly scoped user stories that were exactly what a user asked for, but not thoughtful on my part, nor backed by any metrics/patterns. If the user asked for a report, they got a report. I should have been asking why they wanted a report, and maybe I would have realized they really wanted a dashboard or a list page or an email alert, or if the person who had the job before them left a sticky note that said they needed to ask the IT nerds to build them a report.
I was lucky to have senior-level developers coach me through these product flops. I worked closely with a senior developer once who would make me explain to him in feature refinement what the user/stakeholder was trying to do in each use case. If I launched into my prepared background notes on what I thought we needed to build, and quotes from the stakeholders telling me what they wanted, he would cut me off and say, “STOP — WHAT ARE THEY TRYING TO DO!?” I am very grateful to him now.
In product management, one spends so much time trying, failing and trying again. I have never worked in another role/industry like this. I have worked at tier-one law firms and Wall Street investment banks in non-product roles, and I was pretty sure I had reached the top of the “critical thinking” mountain. I came into product/software development with this false notion I was better than a PM role; I had already done more challenging work with much sharper people. I was dead wrong about that.
I have spent many hours with software developers, UX folks, business analysts, stakeholders and customers trying to collaborate and solve problems. I’ve visited customer sites, walking factory floors and laboratories. I have watched focus groups behind a two-way mirror as they looked at our software — while our team took notes about body language and facial expressions. I have worked with quality engineers to figure out why certain types of latex gloves work on some tablets but not others. Validating a problem up front, incorporating the desired outcomes into your OKRs and seeing it through your roadmap is fundamental to product management. I have seen features designed in portrait mode, only to find out the customer solely used landscape on their iPad.
In Agile software development, you don’t have the luxury to always spend 6 months fleshing out approaches (very often). In many instances, it can be just a couple of months, before a development team must begin work on a feature — just like a raging river that never stops moving — but you have to stay calm and level-headed, and iterate, iterate, iterate.
By nature of working in a product management role, you are trying to solve the right problems (at the right time) and not make new problems for users. It’s all about collaboration and communication with stakeholders and software developers, alike. It’s about doing research and reviewing metrics, so you don’t end up building whatever the last person you talked to asked you to build. It’s about not getting attached to a feature you really like, if the data and other discovery metrics don’t back it up (holding on to a dead branch in the river forever and needing to let it go).
Developing software is about trial and error, not just following a very prescriptive path without deviation. Product management is about diagnosing a problem through many tools, then working toward a goal with an informed approach.
Product management might actually save my life some day.
