How a Web-Development Bootcamp Shot Me into the Product-Management Stratosphere
- Understanding the technical jargon
- Gaining perspective
- Aligning key requirements for the engineering squad
- Getting on the same wave-length (technically, emotionally and professionally)
Understanding the Technical Jargon
I first realized that I likely wasn’t going to continue down the professional path of a web developer about halfway through the bootcamp. However, I knew that I needed to finish for myself and my team. I needed the education because I saw a great need on my team: the PMs over backend technologies in the past did not have the technical understanding of what their engineers were encountering.
There are a couple of real problems that emerge here. Not only does not understanding the technical pieces of your own product lead to actual time and money wasted, but it can lead to long-term issues in terms of planning and execution. On top of these, developers will not trust their product leader if they don’t feel that he/she understands (in-depth) the product they’re managing. This can typically be made manifest with the proverbial eye-roll that the developers shoot back at the product team when they ask them to deliver a solution that seems straight-forward, but in reality is a much bigger technical mountain to climb. This results in a loss of trust towards the product team. My older brother is a seasoned Java developer at a financial technology company. He often will tell me the problems that he has with his product squad:
They never listen to us, and they always are changing their mind on what they want! If only they understood how difficult it was to simply spin up an API…
My older brother is somewhat of a whiner 😉, but he’s right in this case. It is NOT easy to simply spin up an API for the frontend team. It’s even more complicated when you want to surface that API to users or other development teams. There are so many technical pieces to consider, from authentication to traffic routing to payload management, or from state management to normalization of the data. Not to mention the DOCUMENTATION, which NO developer loves to write (and why should they?). When I started the unit of my bootcamp where we built a full-stack application with a Node.js backend, I learned quickly how difficult it was. Even without building a really killer application, I now knew what I was talking about. It removes so many blockers when I am able to understand what developers mean when they’re talking about these technologies. Sure, a PM can learn from working with developers what these things mean, but it takes time to internalize that information, just like learning a real-world spoken language. And as they say with those (and I can vouch from personal experience), it’s always easier to learn the language when you’re immersed in it.
Gaining the Right Perspective
Of course, really understanding the technical jargon will directly lead to gaining the correct perspective with projects that developers are diving into. Developers rely on product managers to clearly define problems and requirements for the agreed upon solution. They also rely on them for stability in sprint management and overall growth/progression towards company goals.
It’s not hard to surmise that if you understand the technical pieces of an OKR or a specific initiative, that understanding will manifest itself through sprint planning and execution. Instead of a specific initiative to “spin up an API”, or even a new endpoint, the initiative instead becomes to identify the correct technology that would allow for specific authentication, routing, traffic management, request handling, error management/logging, etc. These are some of the key building blocks for an efficient and scalable API. Developers will agree with this, which leads them to trust you more as a PM when you’re able to gain the correct perspective into certain technologies and what is actually required. In my developer bootcamp, part of building a full-stack application was to have a planning meeting beforehand with our teams. These were instrumental in gaining the perspective needed to break down specific chunks of the project into more manageable pieces for us to build.
Something else to note is that while you’re gaining perspective into these new technologies and how complicated they can be, you’ll find that this work enforces a bond of mutual trust between you and your development squad. If you understand how difficult or straight-forward it is to implement a certain technology, you can bet that developers will be honest with you in terms of exact blockers they’re hitting, which then leads to quicker resolution. Who doesn’t love quicker resolution times?
Aligning Key Requirements
Now to touch on the specific requirements. This goes hand-in-hand with perspective in that if you understand the technology at play, you know how ambiguous some technical directives can be. In our organization we work from two main documents: A PRD (Product Requirements Document) and a TPD (Technical Planning Document). Typically the engineer handles the drafting of the TPD while the Product Owner handles the PRD. Once both are drafted and worked through can you start to plan timelines and execute, since both the product and engineering squads are supposedly aligned on all the requirements of the task(s).
The main disconnect here is the idea that product requirements listed in a PRD will typically demand more from the developers than what they’re expecting given the overarching objective, which can lead to discord while planning if the PM is not technically informed. This can be quite embarrassing; I had an experience where I was not informed as to how difficult technically a task would be. I ended up having to reschedule a sprint-planning meeting so I could educate myself on the technology. Had I done so prior to the meeting, I would not have had to reschedule, leading to saved time and more developer hours being devoted to actually accomplishing the task. I remember distinctly the evening in June where I discovered exactly what the developer was talking about when I was learning about tying my PostgreSQL database into the server that was powering my application. It was a humbling moment for me to realize that I didn’t have to struggle with developers over that specific piece anymore; they could trust me to come to meetings with a true understanding of the technology.
If the PM can be technically aware, aligning the key requirements of the product into the PRD aids engineers by not having to do a lot of the same work twice in their TPD. It leads to more trust, quicker planning and even quicker execution in my experience.
The Same Wavelength
This one is a bit personal for me. When I was in my first PM gig, there was a new Netsuite integration we were tasked with building. The old one customers were using was outdated and not stable in its performance. Customers were frustrated and it eventually became a common driver for churn. I knew what the problem was, and I knew that the end objective was a functional, stable Netsuite integration. However, I also knew that the technical requirements were massive, thanks to my bootcamp education. There was very little documentation available for the type of integration we were wanting to build, so the developer (bless her heart) had to sift through hundreds of pages of unrelated documentation in order to find the pieces she needed to continue her work. I knew beforehand the pieces that she needed in order to continue with building the integration, and so I was on her same wave-length technically and professionally. We were aligned, but other members of the company were not. To them, it was an integration — how hard could it be? Well, very hard.
It got to the point that due to this lack of technical alignment among differing teams the developer was burdened with stress to the point of needing to take a few days off. I knew this, as well as the VP of engineering. He wanted to protect her based on the immense pressure related to the project. I agreed 100%, and so we gave her time off. Other members of the company, including some PMs I worked with were frustrated. Why did we pause this project when it was already in full-swing? I had to get others aligned on the immensity of the task that was laid before the developer. In retrospect I should have set the expectation much clearer in terms of how difficult this task was going to be for the engineer. Had I done this I could have likely prevented the incredibly stressful few weeks. Regardless, a silver lining here was that I was able to connect with her more personally — even emotionally — due to my experience in that bootcamp. In that moment, the $12k invested became more worth it.
The lesson to be learned here is that developers are human and subject to the same stresses and challenges that we are in product. It is simply presented differently for them. It can be stated that developers should task to understand the product side more (and they should), but I personally prefer to take the opposite approach and educate myself to the technical side of these projects. Doing so has proven that I’m able to remove the roadblocks of technical jargon and understanding the key requirements such that I’m able to connect with the engineering team more. They’re my friends! They’re awesome people and they do awesome work. It was very fulfilling to me to be able to remove these common roadblocks so I could get on their level. When they needed the professional or even emotional support, I could give it. How valuable is that?! Sometimes it appears that nothing could be more of a lifesaver for a developer than a product owner who truly understands their job, or at least a large portion of it.
The bootcamp that I completed was very difficult. It wasn’t just difficult in terms of the actual busy-work, but the mental capacity and discipline to understand manage these very complicated technologies is very challenging, indeed. It is my eventual goal in product management to reach a true state of technical enlightenment (SaaS Nirvana, if you will). My experiences have taught me that striving for this knowledge and enlightenment has improved my relationships with developers, helped immensely with alignment, and strengthened mutual bonds of trust in our organization.