The concepts (not code) I know to work effectively with Engineers.
How I engage with Engineering teams as a Product Manager who doesn’t know how to code.
Hey — I’m now on Substack. Subscribe to get the latest from me here.
The Product School talk I shared recently, from years ago, still resonates with so many folks to this day. I’ve wondered why this talk hits home for many. Qualitatively, I think it’s because those transitioning into Product Management view technical skills as a blocker. Code is another language and working with people who speak another language can be intimidating.
In my talk years ago, I I highlighted that Product Managers need to know “enough” to work with engineers. Today, that guidance feels really abstract. In this post, I’ll break this down further to make my thoughts more applicable.
So what does knowing “enough” mean?
Concepts Not Code
In my presentation, I used the word “concepts” which is a comically vague. Let’s break that down further.
Getting Started — What you need month one:
- System Design & Architecture: This is the technology stack that powers the products you build. It’s important to know the interrelatedness of systems, how they’re powered, what’s homegrown and outsourced and generally how stable they are. I find making yourself a visual here to be extremely useful. Find your Tom and make sure to understand the basics of the tech stack you’ll build atop of.
- Engineering Roles: It’s important to understand how and what different engineers do. A Front End (FE) engineer’s skillset can look different than a Back End (BE) engineer, which is different from a QA engineer or a Data engineer. Knowing some of the key differences between engineering roles will be helpful in planning conversations. Partner with your Engineering Manager to make sure you understand the composition of your team.
Day to Day
Below are some key engineering concepts I think about when I discuss product development with engineering teams:
- Feasibility: Before we decide to build a feature, we scope out a project to determine what is possible to build. Engineers are going to be the experts here, but conceptually, it’s helpful for you as the Product Manager to know which problems are costly to solve. This usually comes in the form of sizing…
- Sizing: Engineering teams size work to understand how complex a feature is to build. Sizing is an art form. You may not know how, nor should you know how to size work properly, but if you attend grooming and planning sessions, you’ll start to learn which work is trivial and which is costly. The more you understand this, the more you’ll be able to advocate for your team and in turn, plan better. If you understand team velocity (i.e. efficiency), you’ll better budget towards working deadlines.
- One Way vs. Two Way Doors: We used this concept at Spotify a lot, especially in the latter half of my tenure, and I loved it. It’s important, as your engineers make foundational decisions, to know which solutions are reversible and which aren’t. Having a good grasp on these decisions will help you manage and communicate tradeoffs to your stakeholders.
- Reusable Tech: As I noted above, it’s incredibly helpful to understand systems and architecture. Knowing this helps you learn about how tech may or may not be reusable. You don’t want your teams building many one-off solutions to singular customer problems. Rather, you want to ensure that solutions are flexible and strategic so that you can repurpose and reuse existing technology, whenever possible. Prioritizing scalable tech solutions and embracing automation makes teams efficient. Which leads to my next note on scale…
- Scaleability: Understanding scale is tightly tied to your product vision. Are you building a tool that scales to many international markets or requires a high volume of simultaneous visits (think streaming!). Knowing which pieces of technology enable or limit your ability to scale is key. In these conversations, it’s helpful to understand what your breaking points are. I tend to ask questions like “At what point does this setup break?” Product health, also known as reliability, will make or break the customer experience. So it can’t be ignored.
Ask the Right Questions + Collaborate Smarter
I spoke about this in one of my previous posts but I’ll dig in a bit more here. Over the years, I’ve learned that most times, bringing engineering into the conversation as early as possible, when we have an unsolved customer problem, results in the best team solutions. In fact, I’ve invited many engineers to listen in on research sessions with real customers. Nothing creates empathy more than when you hear about a problem first hand!
When I rally a team around a customer problem, I like to bring a set of user stories to a meeting. I do this not as a means of dictating a solution or requirements, but rather, as a place for us to start. More times than not, I’m enlightened by the conversation that ensues and how engineers interpret the customer problem. This kind of discourse leads to the best kinds of solutions.
After determining a solution collaboratively, I like to lead with a proposed solution. I’ll also include all the other solutions we considered but didn’t move forward with and why. It’s more work upfront , but it’s a great way to show stakeholders and leadership the full scope of your thinking. And it’s also a great way to document decisions for your team when you inevitably forget why you chose a certain path. Because you will forget.
Inform Decision Making
Much of this I covered above, but it’s another reminder that your job as a Product Manager is not only to define scope, but to defend it. As a Product Manager you sit in between many functions that have competing interests. The more you understand about the engineering setup and products, the better questions you’ll be able to ask to help you advocate for your plans. And, the more you engage with engineering to learn the concepts (not the code!) the better you’ll get at writing clear product requirements, sequencing your roadmap, and communicating decisions and tradeoffs to leadership. And, the better your team will function :)
All-in-all you can be a great Product Manager whether you know how to code or not. In my experience, the more you get to know the tech behind the product, the better product you will build. I’ll leave you with a quote that still resonates with me completely:
“So while it’s good if you have a strong technology understanding, it’s not good to use that knowledge to try and do their (engineer’s) job for them.” — Inspired
Hey — I’m now on Substack. Subscribe to get the latest from me here.
