Curious product #18 - Let's talk about engineering
Why technical decisions matter for the product manager
Do you think humans act rationally? Well, I have bad news. Not we are only irrational in most of our choices but we do so in a predictable way. That's what Dan Ariely shows in this book. A must read for anyone trying to understand customer behavior.
There's a common misconception in product management that PMs should not worry about technical decisions, delegating it fully to the engineering team.
Before we proceed it is important to notice I am not saying that product managers have to make technical decisions, that is up to engineers indeed.
But PMs must get involved in technical decision, especially architectural ones. Why? In time, technical decisions have profound impact in the team's performance and sequencing the product can become a nightmare.
First, let's talk about design
Every PM give suggestions on design. This is natural - we all try to put ourselves in the shoes of the customer and hint on how the experience could be better.
Why isn't it the same for technical decisions that will definitely have an impact on the customer experience and the business?
The common answer here is: “Because I don't have a technical background”. But most people don't have a design background either and they still give suggestions on design. If you think that's because “design is easier” you are missing the point twice:
Good design looks simple at the outside but is really hard to do well
Technical ideas are as hard as design, the problem is that PMs don't practice talking about it often enough
We tend to feel more comfortable with design simply because we are used to look at many of them both as user and as PM. We practice questioning design often enough that we may even feel like we are “experts” (we are not).
So you need to create the right conditions to talk to engineers the same way you talk to designers. Not that PMs do it well, but that's another post.
Pre-condition for talking about engineering
In order to talk to engineers you need to understand (at least a bit) the world of engineers. I am not saying you need to become a programmer, but you do need to learn how to write basic code (there are plenty of tutorials online).
You need to understand the basics of software design and architectural patterns. And you need to consume some content engineers consume. Here are a few resources:
Pointer newsletter: great selection of engineering content
The overflow: Stack overflow's newsletter (if you don't know what Stack overflow is, than you need some catch-up to do)
Cloud design patterns: a great read from Azure to explain how to look at tech from a macro level
Increment: a monthly magazine by Stripe talking about hot engineering topics in a light manner
If you work as a product manager in a tech company and “don't feel like studying about tech”, I'm sorry to say you are probably in the wrong duty. If you want to become a great product manager then you must learn about software development.
It's all about making good questions
Now to the point of all this. As a PM you won't make technical decisions, that's non-sense. But your role is to question the decisions based on your knowledge about the feature to be released and the product strategy.
You need to understand at a high level why a tech lead made a certain decision and how it affects the product now and in the future. Some templates to get started:
How can we test / build feature X we have been discussing on top of this?
I got the idea that you made this decision because we are trying to release this fast, but what would you do differently had we more time? Why? (maybe as a PM you can buy more time)
What happens if our launch is so successful that the traffic is twice what you projected? How much effort it will take us to support such high volume?
How much effort would it take for us to maintain this database that the company's infrastructure team does not support?
The idea is to get the conversation started. Questions often circle around (i) how a delivery supports or not the strategy / vision for the long-term; (ii) corners to be cut to test and a plan for the final solution in case it works (don't forget to read this piece of advice on the topic); (iii) mitigating possible risks; (iv) the cost to maintain the solution in time.
Practice
If you work in tech-related products, you need to know about technology and talk the language of engineers. That comes with practice. If you haven't done it yet, pick an engineer tomorrow and ask him to explain your product (or a part of it) in technical terms. Try to translate that to your own terms and ask for feedback. Fill the knowledge gaps and iterate.
Always be curious,
Thanks for reading.