How to be technical without being technical
Asking the right questions to get the information you need to deliver the value your customers need
TL;DR
As a product manager, you can be technical without having a software engineer or science background by asking the right questions and an open mind to learn.
You can understand technical decisions by asking:
What are the different ways the outcome can be achieved with the business rules described, and how come?
What are the pros and cons of each approach, and what’s causing the pros or the cons?
What would be the long-term impact of the approach, like how difficult or easy would it be to maintain or change?
Which part of the proposed approach creates the most effort, takes the longest time, or creates the most complexity, and why?
How will the approach flow, transform, store, and retrieve the data involved in the approach?
Along with an estimation. This will give you a deep understanding of the options, especially if you ask follow-up questions about how come or why. These answers will allow you to:
Adjust your ask/requirements to better fit your timing based on technical constraints
Achieve the outcome you’re hoping for
Avoid long-term impact on your product and options (acquiring unnecessary technical debt)
Identify future options and feature ideas
Gain a deeper understanding of the platform and architectural decisions’ various implications
Intro
“How technical should a product manager be?” This is a question or discussion that comes up often.
While I believe it’s good for product managers and business leaders to understand how their products are ideated, built, maintained, and improved, I don’t believe they need deep subject matter expertise to make sound decisions. Because at the end of the day, the purpose of any of this is to make better decisions to achieve the desired goal.
Why be technical?
As someone coming from a software development and system architecture background before moving into product and management, being technical comes with the territory, and this knowledge helps me make better product decisions. However, over the years, I have realized that being technical’s only benefit is to help me either ask better questions or short-circuit the process completely and make sound product decisions to improve and work around the technology stack.
However, when I took over a product that has a large data science-driven component focusing on labor and economic model analysis and forecasting, I was no longer a subject expert. So, I am no longer ‘Technical’ and suddenly can no longer take the same shortcuts I could with a software or system development team. This is when I realized that my ‘technical’ ability was nothing more than a shortcut to the answers I needed to make better product decisions.
How to be technical without being technical
Since I don’t have the time to become a labor economist, I took a step back and used traditional SaaS products that I’m already familiar with and tried to figure out,
What decisions do I have to make?
What information do I need to make that decision?
What questions will help me to get that information?
What questions will help me to identify questions I should be asking that I would not have thought of because of my lack of domain knowledge?
After drafting a list of questions I should ask and the information I needed. I tested the model first with my tech team and pretended to be not technical so they wouldn’t be weirded out by the basic questions I asked and to provide a proper test of my concepts. After verifying the questions and a rough sequence to ask them, I tested it out with my data science teams and labor economists, and I found I could speak intelligently with the team and understand the impacts of the decisions I make along with the optimal options to achieve my goals. After a year of working with them, I know enough to try the shortcuts that I did with software and validate my decisions with the economists. I knew that while I was not a subject matter expert in labor economics, I could still make sound decisions about my product and how to deliver value to the customer and the organization.
Recap
Here are the questions I used to get the information you need to make sound product decisions, even when I lacked the technical or subject matter expertise involved in building the product.
What are the different ways the outcome can be achieved with the business rules described, and how come?
What are the pros and cons of each approach, and what’s causing the pros or the cons?
What would be the long-term impact of the approach, like how difficult or easy would it be to maintain or change?
Which part of the proposed approach creates the most effort, takes the longest time, or creates the most complexity, and why?
How will the approach flow, transform, store, and retrieve the data involved in the approach?
If you want to create your own questions, just figure out what decisions you need to make, what information you need for them, and what questions you should ask to identify what you don’t know that you don’t know, and build your own list.
If you are unhappy with your current product’s growth and want to see what’s holding your products back, check out simplifying.work. We are here to help you know what’s wrong, how to fix it, and make it last so you can keep growing.