Technical Product Sense
Aspiring product managers know that “product sense” is a necessary trait to develop — many articles (Jackie Bavaro’s is a good start) have been written on what it is and how to develop it.
I want to discuss an analogous concept, “technical product sense”. This isn’t a real thing, but I find it a useful lens for learning about technologies, and evaluating emerging trends.
Jackie Bavaro says that product sense is
the ability to understand what makes a product great. It’s the ability to hone in on the important problems a product solves and come up with ideas to make it even better.
In that case, technical product sense would be
the ability to understand the problems a given technology solves, and come up with more, better fitting uses for it.
Understand by Comparing
“Any sufficiently advanced technology is indistinguishable from magic.”
Every aspect of modern software development, machine learning, design — when taken in isolation — is cool. However, accumulation of abilities 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.
To start, a product manager must have a broad based understanding of the basic systems of software products. My favorite is a web app. The goal is to establish a framework that you can use to evaluate the pros/cons of any given technology.
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 the new concept by comparing it to one you already know, then fill out your understanding by identifying their differences. 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 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.
If you don’t have such a person available, email me at pmtechlessons@gmail.com . I’ll do my best to respond, and gather the most interesting questions into a published AMA at some point.
I suggested 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”.
Dividing Lines Don’t Care About Step Size
For product managers further along their technical journey, I want to give more specific advice for that can be more applicable to your actual product.
Innovation happens when the previously impossible becomes possible. Alluding to the section title, it doesn’t matter how big or small the change is that brings an idea into the realm of possibility. All that matters is that it is now possible. In relation to product management, it’s critical to distill any project down to the fundamentals of what it’s trying to accomplish. Only by knowing what your goal is can you tell what is still missing.
The magnitude of change doesn’t necessarily correlate to the magnitude of improvement it brings. Be nimble and flexible on the potential applications of anything you evaluate, keeping in mind that technical evolution can often bring equivalent outcomes, but doesn’t strictly replicate an existing process. As Bezos said, “Stubborn on the vision, flexible on the details.”
A credit to Richard Hamming’s The Art of Doing Science and Engineering for inspiring many of the ideas in this article. If you read it, I suggest chapters 4 and 5.
Keep Learning
Finally, I want to end on a point I first made in How Technical Should PMs Be?. The most important threshold to cross in developing your technical product sense is not being afraid of learning any technical concept.
It’s okay to attempt to learn a concept and fail. To be successful as product manager though, you can’t afford to miss out because you didn’t even try to learn in the first place.
Programming-curious?
I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.