5 things every product manager should 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.
Here are a few topics that are worth studying a bit.
How the internet works
The architecture for how the internet works controls most decisions your engineering team makes. Understanding how the overall pieces fit together will help you understand technical decisions, limitations, and even team organization.
This may seem like a large topic, but the fundamentals are pretty easy to grasp. A few introductory topics:
1. Server — In very basic terms, a server is a computer somewhere that’s always on and serving up something for you (for example, the backend of your web app).
2. Client — It depends on the context, but oftentimes the client is your (or one of your user’s) laptop or phone.
3. Client/Server communication — This is a broad category that encompasses an immense number of technical topics, but in general they’re all there for the same purpose: enable communication between clients (your user’s computer) and servers (your backend). Some of the many things you’ll hear that fall into this category: DNS, HTTP, TCP/IP, API call.
4. The Cloud — As the old joke goes: the cloud is just someone else’s computer.
5. The (very) Basics of Web App Architecture
This is an extension of how the internet works, with a focus on how most modern web and mobile applications function.
Here’s a list of some initial topics you should familiarize yourself with:
1. Frontend — Generally speaking, this refers to the code running in each user’s browser (client) and the associated user interface that your users interact with.
2. Backend — This refers to code running on servers your company controls, and is where most business logic happens.
3. Database — This is the technology that stores all of your application’s data, running on a server that your team controls.
4. SQL queries — Assuming your database is a SQL variant (PostgreSQL, MySQL, MSSQL), writing SQL queries is how the backend interacts with the database to store and retrieve information. It’s also often how initial analytics data is gathered, so learning the basics of SQL in order to query your own information for reports can be helpful.
Open source libraries vs. custom code
Open-source libraries are essentially small chunks of code that some kind of engineer out there has offered up for free for anyone to use. Nearly all modern web apps use an immense amount of open-source code.
From a product management perspective, the main category of open source software that you may make a decision on is UI elements since whether your engineering team uses certain libraries on the backend in a manner that your end uses won’t ever notice doesn’t really matter to you.
Open-source UI components offer mostly a large upside: they make it faster for your engineering team to implement your app’s user interface. In general, the main negative aspect to consider is that your app may end up looking similar to a lot of other apps (for example, a whole lot of web apps use Google Material right now, and that has led to a somewhat unoriginal look and feel).
I recommend using an overall UI framework like Google Material if you’re in an early stage and you need to get a functional MVP as fast as possible. If you’re in a later stage with your app, I recommend having your team put together its own design system for a little bit more identity (though the underlying code may certainly still be based on open-source libraries).
Technical debt
Technical debt refers to poorly structured code in your application that needs dev time to refactor into cleaner, more maintainable code. It’s called “tech debt” because it’s the same concept as monetary debt: you take out a “loan” to get some feature done faster, and that accrues technical debt which you have to pay back later by having your team refactor it.
Why would you do this?
The same reason anyone takes a loan in real life. Sometimes you need to get a feature done as fast as possible to appease a customer or make an important demo, and that can be worth accruing some tech debt that you build into the next few sprints after the milestone.
The analogy goes a step further: tech debt likely makes some portions of your app more time-consuming to work on (effectively you have to pay “interest”).
Tech debt is neither a positive nor a negative, it’s simply another tool in your toolbox. There’s one main rule to keep in mind: if you’re going to accrue tech debt, make sure you have a plan to refactor it out as soon as possible. If you neglect to do so, you may end up with so much tech debt that your team’s progress slows to a crawl.
Automated testing
Automated testing is the practice of writing little pieces of software that tests your application to make sure it functions correctly.
There are many ways to approach it, but there’s one main consideration that’s important for product managers: automated tests take effort to create, and pay off over time.
Leaning on team members to manually QA your application can work initially, but it will soon become unwieldy as the complexity of your app grows. Eventually, it will become effectively impossible to manually test every part of your app, and bugs will slip through.
Generally speaking, your engineering team should ensure automated test coverage is reasonably high for all aspects of your application. If this is impossible for some reason for a certain release (for example, your team is rushing to meet a deadline), then consider it the same as technical debt: work that you know you have to catch up on later, sooner rather than later.
From a product management perspective, it’s important to remember that automated tests benefit you just as much as anyone else. If tests aren’t in place catching bugs, it’ll be your customers complaining to you instead.
Conclusion
Product management is a bit of a “jack of all trades” discipline: there are a million things you can be learning, and many of them are equally important. Alongside all the traditional continued education, I recommend keeping up on the latest in web development patterns at a high level. The more you can empathize with and understand your engineering team, the easier that relationship will be.
Further Reading
Hackernoon’s article on technical skills for non-technical product managers covers some of the same basis, but with a different twist.
Appcues’ article lists softer skills that are important for product managers.
This guide to product development roadmaps is helpful for product managers who need to present roadmaps to executives and stakeholders.
Contact us to talk more about software development and making great products.
