So you just started in your first job as a Product Manager… First of all, congrats! If your first instinct is to marathon every Codecademy course in their library, pause and slow your roll.
Me looking at my company’s Github repo
One of the questions I get asked most by prospective and junior PMs (especially those transitioning from business backgrounds) is what technical skills they need to learn. As someone who’s functioned in this role without a computer science degree or bootcamp certification, I would prioritize building knowledge in these areas:
- Data instrumentation and analysis: Using data to pinpoint user problems and track performance post-launch is one of the core parts of a PM’s job. At minimum, this involves high proficiency with event-tracking tools like Amplitude, Mixpanel, and Google Analytics. You should not only know how to set up funnels and dashboards, you should also know what events to track and what properties to capture. Beyond that, I recommend learning SQL (Codecademy has a decent course—there are some minor differences depending on what database you use, but the fundamentals are the same). Not only will SQL give you a better understanding of your company’s data model, it allows you to perform deeper analyses on financial impact and long-term retention. SQL is even more important if you’re working at a small startup without dedicated analysts, and you’re relying on engineers for data pulls.
- Rough engineering estimates: Yes, engineers should own estimating sprints/weeks for features and story points for tasks. But, if you have a general sense of T-shirt sizing (S/M/L), you can save valuable time in triaging bugs and stories. This allows you to immediately reply to the person who reported the issue with something like, “This shouldn’t be too hard, but give me a day to confirm with engineering, and I’ll let you know when we can tackle this.” It also reduces the additional productivity loss associated with asking engineers to context-switch every time you need to provide an estimate.
- High-level system architecture: Develop a functioning understanding of all the different apps and services your company has, and how they all fit together. Doing so will help you reproduce bugs more quickly, and formulate hypotheses on what’s causing the issue. With that information, you’ll be giving your engineers a head start on tackling the problem, again saving valuable developer time.
- Basic end-to-end software development process: Familiarize yourself with your company’s workflow for creating, reviewing, and landing changes in code. Understand how different environments are set up (i.e. development, staging, and production), and how to deploy things from one environment to the next. If you work on mobile apps, learn what changes necessitate a client release (with a multi-day Apple review process) versus what can occur server-side with shorter turnaround. This will help you budget enough time to meet launch deadlines and deliver polished features to your users. (Sidebar: Can someone make a version of the Schoolhouse Rock “I’m Just a Bill” video for how a new branch becomes production code? 100% would watch 🙏🏽).
- Tradeoffs of different programming languages and tools: As a PM, you should be able to talk about what stack your engineering org uses, and describe why they chose these technologies. Again, this does not mean you are writing production-quality code. Rather, it means knowing enough about the codebase so that you can ask good questions when engineers are discussing tech debt and help them prioritize these efforts against user-facing features.
- Applications of new technology to your users and product: Stay on top of the latest developments in tech by reading news/blogs, attending workshops, listening to podcasts, etc. For instance, Apple unveiled its ARKit functionality during its iOS 11 announcement back in June. When events like these happen, it’s your job to think about interesting ways to integrate these tools in your product — turning your bathroom mirror into an AR dressing room in your ecommerce app, for instance, or conjuring up bad guys to take down in your fitness boxing app.
This may seem like a daunting amount of knowledge to acquire, but the simple strategy is to ask questions and don’t be afraid to look stupid. When we set out to build a recommendation engine at my previous company, it took four excruciatingly slow explanations for me to understand how our queuing service, user events, machine learning model, and in-memory database all fit together. This sense of inferiority was exacerbated by the fact that I was the only woman on a team of six men, all of whom were more technical than me. But the alternative was to nod along and pretend like I understood when I didn’t — a disastrous move that would have left me wholly unprepared to improve on the platform we built.
Me in our technical design discussions
Finally, Googling more general questions about different tools and up-and-coming technologies can never hurt. Half the time, your engineers are doing the very same thing; they just may have a better understanding of the results. So without further ado, go forth, ask questions, and fake it until you make it.