Some technical knowledge is helpful for managing internal products
If you work on internal products, the more you understand software development, the more effective you’ll be in all product management aspects.
This week I want to tackle the activity of development for internal products. Specifically the actual work of developing and testing custom internal products, or configuring and testing off the shelf or SaaS products.
Development shouldn’t be a second class activity
For some reason, development has gotten a bad rap in the product management community. It happened when discussions about outcomes and discovery - both key concepts for product management - some how turned into adversarial conversations.
As in:
Outcomes vs outputs
Discovery vs delivery (In this case, delivery is the catch-all term for all the activities required to actually make the product).
I suspect the conversations became adversarial because a majority of product teams (still!) tend to plan and measure success based on the outputs they produce and spend most of their time focused on delivery aspects.
This is especially true in most internal product situations because teams are trying to break free of the IT as a cost center mentality that enshrined an output focus.
Changing that mentality does not mean swinging the pendulum all the way to the other side, it means finding a balance.
You should strive to reach maximum outcome with minimum output, and you won’t get any outcomes without any outputs.
You need to take advantage of the mutually reinforcing nature of discovery and delivery.
Someone’s got to do development
Now, I’ll be the first to state that in order to do more discovery (preferably continuously) for internal products, product people are going to have to reduce the time they spend on delivery.
Actually, considering the 7D’s as I’ve described them, business analysts, product owners, and product managers need to spend less of their time on development.
Easy, right? After all that’s what the engineers are there for.
In theory, yes. In theory, product teams could behave like Jason Knight suggests where product people aren’t responsible for delivery.
That of course relies on engineers leading development and not relying on product people to tell them what to do next.
I’ve worked with a fair number of engineers on different product teams over my career. There are engineers that led development when I worked with them. It was wonderful.
And there are engineers who… don’t. In fact the majority of teams I’ve worked with exhibited this trait.
Finding balance requires knowledge and collaboration
So if you find yourself working with developers who look to the product person to guide them, you need some technical knowledge to do that effectively.
In the short term, you need to understand how your product works so you can effectively and efficiently break up work.
Over the long term, that technical understanding helps you build credibility with your team so that you can build the mutual trust necessary to work in a more collaborative manner.
One reason that some product people spend such a large percentage of their time on delivery is because a lack of understanding leads to swirl. Plus, if they don’t have a collaborative relationship with the engineers on their team, they also have to spend an inordinate amount of time in conversations, usually talking at each other rather than quickly building a shared understanding.
So with that in mind, I wanted to share some perspectives on the technical knowledge it’s helpful for product people to know.
These resources are about software development in general. From my experience I’ve found some areas are particularly important when you work on internal products:
Security and compliance - what regulations are particularly relevant for your organization and what steps from a technical and policy perspective does your organization take to address them?
Integration with existing systems - when you work on internal products you will inevitably have to interact with other internal systems. Do you know where the data is buried, how those processes work, and what APIs are available?
User adoption and change management - contrary to what you may have heard, users of internal products do have choice when it comes to using your product. They can choose to find workarounds or use your product in exactly the way it wasn’t intended.
Take a look at these perspectives and let me know your thoughts and experiences.
What technical skills should product managers possess?
Aspiring product managers often wonder how technical they need to be to crack their next PM interview.
Alas, even in the industry itself, there’s no consensus. One camp believes PMs just need to empathize with users and don’t need technical aptitude. Others believe a PM without tech skills is like a construction manager who doesn’t know how to build a house.
Moreover, different settings require different skill sets. Bart Krawczyk, Senior Product Manager at Brainly, provides his perspective on “how technical” product managers should be.
Explore Must-Know Technical Concepts For Product Managers
Software product managers with no previous experience in a technical role and who do not know how to write code can now loosen their grip on soft skills and transferable skills. Those are great but not always enough. A reasonable knowledge of software-related concepts is also needed.
The role of a software product manager also known as a digital product manager is to oversee the entire lifecycle of a digital product from inception, launch, and post-launch. It is only logical that added to PM skills some technical understanding is expected, especially for PMs in early-stage startups.
Peculiar Ediomo-Abasi - product manager, ux designer, and freelance writer - compiled a rich list of helpful tech resources for a product managers. Peculiar arranged the resources in a way to give you a crash course on relevant software-related concepts that non-technical product managers should know.
11 Software Development Best Practices in 2024
From the don't repeat yourself principle for software bugs and implementing version controls to enforcing naming conventions and designing before coding, there's no shortage of software engineering guidelines to follow.
Weronika Włodarczyk, Python Developer at Netguru created a handy list of 10 software development practices that her team stands by. While this article wasn’t necessarily written for product managers, it’s helpful to know what good practices your product team should follow.
A Technical Guide for Product Managers
One of the most common questions aspiring PMs ask is “Do I need to be technical to be a product manager?”
Will Lawrence, product manager and author of ProductLife, also pondered the question “Do I need to be technical to be a product manager?” and did some research to determine the broader consensus on the topic. There appear to be two camps of responses:
No, you don't need to be technical: PMs focus more on building the strategy and coordinating the many roles involved in building a product.
No, but it helps. It’s unnecessary to have a technical background, but it sure helps build credibility with the team.
Over the last few years, Will’s answer to the question has evolved. He’s now firmly in camp number three: yes, you need to be technical to be a product manager.
Will explains why he thinks product managers need to be technical.
5 things to know about software development
As a product manager, you might think there’s zero chance you’re ever going to learn anything about computer science.
But learning the basics of software architecture can go a long way in understanding how long development will take, what’s possible, and why your engineering team says the things they do.
Jesse Streb - Global SVP, Engineering & Technology at DEPT - shares a few technical topics that are worth studying a bit.
Thanks for reading
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.
Talk to you next time,
Kent