A detailed guide to becoming a technical product manager with links to relevant resources and courses.
Good PMs add to engineering teams. You don’t have to know how to code well in order to understand the fundamentals of what happens under the hood of a web browser or how to query an API endpoint or even design a database data structure. Understanding the fundamentals of programming, at the very least, helps you understand what engineers on your team are saying when you are having a conversation with them. And understanding the technical feasibility of a feature or product is an advantage.
In fact, it helps you to do your work better. Take for example you are working on an API driven product that you need to write functional specifications for. You need to understand the logic for fetching data from a hosted API server without the frontend experience coupled with it and other concepts like protocols, data formats, authentication, API design, and real-time communication.
It’s okay to ask for help from your engineers when working in such an environment but then again it helps if you can anticipate what will be happening in the actual implementation. I find that being able to understand the basic principles of programming really helps inform product thinking and working with engineers more straightforward. If you can clearly communicate the requirements of a feature, you will end up much closer to being on the same page with your team from day one.
Remember, it’s not important to be good at coding. You are in no way required to become a developer yourself. You are merely learning fundamentals and concepts so you can more successfully communicate with your team and also be aware of and assess organizational bias in technical decisions. From my experience with interfacing with engineering teams, I will try and take you through the most basic concepts and tools that will help you improve technically and the resources to guide you.
1. Software architecture for product managers.
I will be sure to remind you again that this is the role of your engineering team, so there is no need to be thorough with your understanding. However, during product ideation, you should be able to translate business requirements to technical specifications for your team and scoping software architecture is a discussion product managers should be able to contribute to. You should be able to identify the stakeholders required on the project. It is important to identify domain architects with the right expertise that affect the product. For example, if you have already identified a microservice architecture with components like data pipelines and messaging. You would typically require an engineer that has experience with Kafka technology or other publish-subscribe systems. Another reason is choosing the technologies for the implementation of each component and the connections between the components. Now that you have a team to work on the project, you will need to plan on implementation and the resources required for the project. And discussions such as when to use open source or to go proprietary will come up, you will need to navigate a sea of issues like the cost of the technology, what do you need the software to do? what attributes should the technology have? where does it fit into the rest of your infrastructure, and business objectives? These questions guide the rest of the discovery and recommendation process.
You can start by reading books that introduces the concepts and best practices of software architecture — how a software system is structured and how that system’s elements are meant to interact. Software Architecture in Practice (3rd Edition) by Len Bass, Paul Clements, and Rick Kazman is a good book with practical case studies that can help you get started. Another great site with a detailed resource is Microservices.io by Chris Richardson.
Tweetzine from Mariko Kosaka explaining browser/server comms (Cont….)
2. Learn more about your company’s stack.
You should be able to identify what programming stack your company uses or what stack is suitable for a product and even contribute to such discussions. Again it is the responsibility of your engineering team to select a suitable stack for projects but it helps that you are able to know the stack preference of your company and the reason behind the chosen stack and how well it works for your particular use case. For example, if you are working on a data visualization and processing product, you should be able to identify ELK stack (Elastic search, Log-stash, and Kibana) or any other stack as the preferable technology and identify engineers with experience using such technologies.
Understand the basic concept of the language your company uses and their limitations and why it is the preferred language. For example, if your company’s frontend is React, it is important that you understand what components, element, and properties are in React. All programming languages have a practical tutorial to help you get started and also a resource to learn concepts of the language step by step.
This Javascript tutorial from CodeMentor for beginners explains in detail how Javascript properties work along with functions, loops, variables, threads, and more. You can also get started with this introductory and friendly article to Javascript functions from Mozilla.
There are several engineering blogs from teams like Uber, Airbnb, Netflix, Facebook, and Google that have cultivated a culture of sharing best practices and their experience with a particular language that you can follow. Be curious in your search for knowledge.
3. Follow up on new trends in engineering and best practices.
Since software involves assigning names to abstract concepts, there is an enormous amount of jargon in tech and it can be hard to keep up with them. Don’t stress it, the fact is that a good amount of engineers are focused on being good with a few technologies than learning every new technology on the block. You don’t have to be an engineer to understand shifting trends in software engineering. Almost every time there is someone working on continuously improving how software is built, for example GraphQL is gaining momentum as the new standard for building API’s, companies are adopting the use of Kubernetes for container orchestration, Docker is the leading technology for containerization and service virtualization, the FaaS (Function as a service) ecosystem is offering companies a pay as you go model to scale their backend infrastructure and achieving a “serverless” architecture . These are all very relevant trends that you should understand as a product manager and will help you communicate better with your team.
The New Stack is a great resource with in-depth analysis to follow on new technology services and infrastructures from various networks of developer and communities.
Tweetzine from Mariko Kosaka explaining HTTP 2
4. Be conversant with technology platforms offering backend as a service.
if you are working directly with engineers in your day to day role. You should be familiar with technologies for real-time communication like Firebase, Pusher and Socket.io, application and API performance monitoring tools like New Relic, Datadog, Apigee, Cloud watch and Sentry, communication delivery tools like Sendgrid, Twilio and Message bird, Identity management tools for authorization like AuthO and Okta, search and discovery tools like Algolia and Elasticsearch and automation platform like Zapier and Airtable and deep linking platforms like Branch. As a product manager, these are tools that you can introduce into your development workflow to help your team automate tasks that would take a very long time to spin up a backend for or even manage. Help your team focus on what matters instead of managing your own infrastructure especially if you are a startup with a small team.
You can follow Stackshare and Siftery, both are community first resource sites where teams from top technology companies share their technology stack as well as advice on how to use them.
5. API’s and how they deliver value for your business.
If software is eating the world then API is eating software. API’s are basically the bread and butter of software. Chances are very high that your barber or hairstylist has an API they want you to plug into. If you are working on an API driven product it is rewarding that you understand the foundational terminology and have a mental model of what an API is.
Everybody uses an API and it’s the current way to build abstraction in terms of the way business leverage technology to deliver value, maintain agility, and leverage its own data. So chances that you are not working on such product are slim. You already know what an API is, but you can still go further by learning how API’s are designed, what webhooks are, protocols for client-server interaction and authentication, how to bundle API into SDK’s, data formatting and what API gateways patterns are. Even how to test your API’s by firing up an HTTP Client to make a few requests to a server.
An easy way to start using an API is with an HTTP Client like Postman, an API development environment program that lets you quickly build HTTP requests to test with. You specify the URL, headers, and body, and the program sends it to the server properly formatted. Even if you decide not to try your hand at implementing an API, you can feel comfortable when they come up in conversations. Postman’s blog is a good place to start learning what API’s are and how you can start querying API endpoints yourself. Another resource is Zapier’s — Introduction to API course and API academy where you can learn the basics of API management.
Here you can see the Postman’s solutions complete list.
6. Learn continuous integration and continuous deployment best practices.
if you are big on adopting the best agile practices in your company then you should know that continuous Integration, delivery, and deployment (CICD) are best workflows for great engineering culture and quality. In fact, you should be an advocate for such standards that drive automation and continuous improvement.
Most important of all, these standards of shipping software product will lead to a more happier team which of course is what you want. By adopting such standards you will, in turn, drive a more collaborative, experimental and quality first approach to product development. The fact is your engineering team do not expect you to be the one to implement a CI/CD pipeline but they expect you to be forthcoming in your approach. Make the extra effort to have a basic understanding of CI/CD automation suite and how to get a continuous integration workflow set up. Be proactive in your approach, don’t wait for your ship to come out, swim to it.
This introductory article from Mind the Product will get you started easily on how to approach continuous integration and delivery as a product manager and this guide from Martin Fowler’s is an easy to read resource on CI/CD. You can make extra effort to check out ebooks from Oreilly books.
7. Leverage data analytics and customer segmentation tools.
Smaller and tighter-knit Startups are typically not built out to have a product manager for each role, in the case where bigger tech companies have a product manager for growth and SEO, customer experience, platform product managers and even for each product. You are probably interfacing with your sales and marketing team if there is any, to begin with. The experience of learning to multi-task, developing self-learning skills on the job, and being adaptable to all the several hats you wear every day can be exhausting.
Resourcefulness is your biggest strength, what tools are you leveraging to help you overcome difficulties? With tools and platforms like Optimizely, Segment, Mix panel, and Kissmetrics, you can create experiments and scale A/B testing across your customer lifecycle to validate and measure the impact of new or redesigned features and get results on your dashboard within a short period of time. Before you would have to stretch your company’s resources and team to do this, but with just a simple setup and configuration you can start collecting and measuring user engagement within hours. The more you interact with these platforms and tools the more you become more familiar with them and can hack them to your specifications.
8. Querying and managing data.
Storing, querying, and manipulating data is a skill set that almost every product manager posses but writing such SQL queries can be difficult and take a long time to write. You can leverage powerful database client like Postico and Tableplus with a friendly GUI to help you query and manipulate your database in no time. Postico is a PostgreSQL desktop client and Tableplus is a tool for relational databases like MySQL, PostgreSQL, SQLite & more. You don’t need to have a strong command of SQL to run quick queries in your database. “Postico provides an easy to use interface, making Postgres more accessible for newcomers and specialists alike”.
Conclusion
I have mentioned a range of resources to learn from but by far the best community I have seen is The Practical Dev by Ben Halpern, Jess Lee, and Peter Frank. Personally, I say it’s the best because it promotes a culture of inclusiveness and encourages healthy discussions and debates.
Also, register and attend engineering workshops and webinars. They are more hands-on than reading engineering blogs or forums.
It’s easy for you to say “ its not your responsibility to figure the best technology to use or the software architecture of a product” but then again you are working in an industry that requires you to be a perfectionist and generalist. Saying “I don’t know” doesn’t have to be a bad thing, “I don’t know” gives someone the opportunity to help you. And it’s important that you work with people that promote a culture of togetherness and team-first approach to work.
Cultivate a habit of curiosity. Learning new things is far easier and can be done much faster than everyone thinks. You are going to get stuck at something but be persistent with learning and whenever you can, ask for help from a teammate.
Self-education is a lifelong curiosity.