How to Not Give up When It Gets “Too Technical” (With Tips) – Issue 9
A 3 step guide on how to work with Engineers
“There is no failure, remember, except in no longer trying. It is the courage to continue that counts.” ― Chris Bradford, The Way of the Sword
Summary
This 3-step guide will help you as a Product Manager👇
Achieve communication fluency with your peer engineers.
Avoid the lost-in-translation trap.
Ship features faster.
Argument #1: "This Code Is Shit We Have to Revamp"
Taking arguments like this at face value will LITERALLY DESTROY your career as a PM.
You'll be known as the articulate PM that talks well and never get anything done.
Take a step back and write after me.
Tell the engineer to write a nontech ELI5 doc to sell you the revamp.
They should cover these points:
What will happen if we don't revamp?
Performance will be improved, by how much?
How much time will the revamp cost us?
Current code slowing us? by how much?
If they a) don't write the doc or b) don't have specific numbers or c) don't have a good argument for the revamp. Then there will be no revamp.
This is important for 3 reasons:
It's a natural bias to think that "Starting Clean" is much easier than "Understanding what exists".
A Great engineer understands the business then chooses the right tool.
An Avg engineer chooses the tool then understands the buisness.
Argument #2: "This Will Take Us 3 Months to Deliver"
🔴 PM Bad Answer: "That's too much, but hey! you know better".
🟢 PM Good Answer: "That's too much, can you walk me through the breakdown cost of each item".
When estimates get crazy it's critical that you wipe out the bottlenecks.
Example: You’re building a new page.
Dev: "Here's the breakdown: 30 days creating the filters & 5 days creating the list".
You: "Filters are not important, let's drop the filters and keep the listing".
What happens if you don't understand the breakdown?
Don't give up! ask for clarity.
Dev: "Here's the breakdown: 15 days routing design, 3 days ingestion, 8 days Redis caching".
You: "Can you please remove the jargon? explain it to me in baby steps".
Argument #3: "We Need Two Months of Investigations before We Implement"
This is a recipe for disaster.
Any investigation should be timeboxed to one week MAX.
If it takes more than one week then you should break the investigation into smaller chunks.
Discuss with your fellow engineers how can they split out the investigation into smaller achievable tasks.
Worrying about efficiency in the wrong places and at the wrong times will slow you down by at least 10x.
Explain that investigations when not clearly scoped will result in never-ending research. Premature Optimization is the root of all evil.
Want more stories like this?
Give me a follow!
I write about my journey in building Enterprise SaaS and Marketplaces
