A Technical Mindset
👋 Hi, I’m David, an APM at Yahoo and creator of PM Tech Lessons. Thanks for letting me into your feed today here on PM101! I hope to offer some useful perspective on the technical side of product management.
I’ve seen a lot of confusion and anxiety around the technical requirements for becoming a product manager, so much so that I’ve created an entire site devoted to the topic (pmtechlessons.com). In this article, I’ll share three thoughts on the topic:
- An example of why the product role requires technical sense
- An exercise to develop your technical sense
- A litmus test for evaluating your mindset towards technical concepts
Let’s jump in.
Why Have Technical Knowledge?
Product managers are the API to their product. They are the interface between requests from end-users and the internal tradeoffs needed to deliver the experience.
An “intuitive” product is high praise, but building an intuitive product is not easy, and is always intentional. The difficulty lies along the edges, the ghosts of past decisions that come back to haunt your team. Being technical allows you to navigate this in two ways:
Translation.
The key to an intuitive product is fully anticipating the needs of the user and building a system that nails every single use case, rather than shrugging at the edges. If a product manager only had one responsibility, it would be to fully represent the best (most intuitive) experience for the user. You enable that experience by ensuring an accurate translation of a feature request into an engineering request. The product manager embodies the spirit of a feature, and by internalizing the consequences of necessary tradeoffs, you will ensure the spirit doesn’t get lost between ideation and execution.
Forwarding-facing planning.
The more you understand the constraints of a system, the better informed your choices around it will be. That includes taking the full roadmap into account when setting initial requirements. Extending your product strategy to include technical architecture will preempt incompatibilities down the line, and give your engineering team a chance to weigh in on how to achieve the product vision.
The same feature can be accomplished by a simple system that just barely meets the requirements, or a more complex one that has room to grow. The right answer depends on your plans, and being able to tell the difference.
Developing Technical Product Sense
Accumulation of knowledge is not useful. Knowledge of technologies is only useful if you can find a problem to apply it to. For product managers, this is the same problem as turning a quarterly planning doc into launched features. Application of your technical knowledge is part of execution as a product manager.
When you approach a new technology, I suggest repurposing a common exercise used for developing product sense: “Uber for X”. Test your initial understanding of a new concept by comparing it to one you already know, then fill out the rest by identifying the differences. The goal is to establish a framework that you can use to evaluate the pros/cons of any given technology. For example,
JSON is like an excel spreadsheet for programs because it gives structure to data that allows it to be read by its recipient, but has the advantage of being more nest-able than CSVs.
I’ve found that having an expert (or really just anyone who knows more than you do) to ask questions to is the most efficient way to bootstrap your understanding. By using the shell of the technology you already know, you know where to look for pros/cons, your “investigation” has direction instead of aimlessly gathering facts, and the knowledge you receive is immediately applicable (by using it in your comparisons) rather than being theoretically useful.
I suggest using web apps as your foundational framework, but if you happen to have sufficiently deep technical knowledge in a non-computer-science field, I’ve found that it can usually suffice as well. The main purpose of any such framework is to help identify the most valuable next question to ask. Eventually, you’ll learn enough about computer science concepts to start making these comparisons “natively.”
A Litmus Test
A Google search can reveal computer science course curriculums, bootcamp curriculums, and “must know concepts” lists. While a fine starting point for those who are spinning in search of a path, grasping too tightly to these lists provides a false sense of security and completeness.
In truth, there is no limit to which technical concepts you can learn — for one, you could become an engineer and secondly, not even engineers know everything. A more sustainable approach is to develop yourself to the point where there’s no concept you’re afraid of tackling.
Most developers don’t know how to do most things before they start, as evidenced by the constant desire to take on new projects, new teams, even new companies to satisfy the urge to work on new problems. But not knowing how to do something should never prevent you from figuring it out. For product managers, technical expertise is not defined by what you know, but by how you can develop what you don’t know.
Learn to learn. Start with the comparison exercise, asking questions, but don’t stop there. Find and double down on the techniques that work best for you, whether it’s building a project yourself, watching tutorials online, or reading articles like this on PM101 and PM Tech Lessons.
The most important threshold to cross in developing your technical product sense is not being afraid of learning any technical concept.
The mark of a good product manager is not knowing all the answers, but knowing how to find them.
Another big thank you to Thaisa for letting me into the PM101 feed today. If you liked you what you read here, you can find more articles at pmtechlessons.com, where there’s a newsletter signup as well.
This article draws from three of my existing articles, which have expanded thoughts on the topics presented:
