4 Lessons From Top Product Managers

Before the year comes to the end, I want to take a second and express my gratitude. Thank you for being a subscriber, thank you for your feedback, and thank you for taking time out of your day to read my newsletter.

Your motivation to be better than you were yesterday inspires me to do what I love and for that I'm grateful. Thank you.

Happy holidays, happy new years and YOU GOT THIS 💪🎇

If you've got some extra time on your hands in between the holidays and new years, take a look back at 2023's tech essays and 💡tech terms.

• Jan: Best and worst traits of PMs I've worked with 💡Async & Sync processing
• Feb: Use ChatGPT to level up your technical chops 💡Webhooks
• Mar: How to prevent, manage, and fix technical debt 💡Domain Name System
• Apr: Building a feedback loop w/ internal teams 💡Libraries & Frameworks
• May: How to build trust with your engineering team 💡CORS
• June: Handling technical interview questions w/o a technical background
  💡Proxy Servers
• Jul: Managing project deadlines as a PM 💡Blockchain
• Aug: PM's Guide to Cloud & Serverless 101 💡Single Page Applications
• Sept: Part 1: 3 API protocols you need to know 💡HTTP
• Oct: Part 2: REST API components and how to read them 💡API Rate Limiting
• Nov: Part 3: PM Best practices for Debugging APIs 💡OAuth 2.0

More to come in 2024!

$250k guaranteed salary to $0.. oh yeah, and in the middle of a pandemic.

I left my cushy software engineering job at Amazon in October 2020. Before that, I’d evolved to become a skilled engineer over 10 years by pushing through and learning from whatever challenges I faced. What’s crazy is the struggles that pushed me the most didn’t always show up in code.. they showed up in conversation with product managers.

I’ve worked with PMs at large agencies, successful startups, and established tech companies. It didn’t matter the company size, industry or prestige—the industry as a whole is still trying to figure out the nuts and bolts of the product management role. What are a PM’s goals and responsibilities? What skills do they need? How much say and influence do they have?

But the question I’m most pre-occupied with: What’s the best way for product managers to work with engineers? My preoccupation stems from my own frustrating experience not knowing how to communicate with product managers in a way where both our perspectives were heard and our needs met.

I know many of you feel the same way working with engineers, especially if you don’t come from a technical background. Maybe you struggle with imposter syndrome, or knowing the “right” questions to ask. Take a breath because you’re not alone!

Still, some of the most impressive product managers I’ve worked with didn’t have any prior development experience. What they did have was enough technical knowledge to ask well-informed questions, the right mindset for working with engineering teams, and a clear understanding of what was expected of them.

So to close out 2023, I want to share with you the knowledge and mindset of these product managers so you too can build credibility, trust, and influence with your engineering team. My hope is that it’ll give you clarity and confidence in navigating your own relationship with your engineering team going into the new year.

1. Know your vision inside and out

.. and be prepared to communicate it!

Devs look to their product managers to understand what the vision for the product/feature is and what they’re expected to deliver. This doesn’t mean you need to figure it all out on your own. Of course you can (and should) get the input of stakeholders early on as you’re defining the customer pain point and refining the nitty gritty details of the product. But if the expectation of engineers is to build the damn thing, then the expectation of product managers is to know what needs to be built and why.

Software engineering is a precise discipline that doesn’t play well with ambiguity. Computers do exactly as they’re told which means engineers writing the code also need to know exactly what the features are and user experience should be.

If you show up at your team’s requirements meeting unable to answer fundamental questions or appear uncertain about how the feature works or what the customer journey should be, you’re unlikely to meet expectations. This will lead to frustration among your engineering team.

Do this:

• Be obsessed with your product: Your product is your baby. You own it, you nurture it, and you’re responsible for its health and success—from 0 to 1 and from 1 to 100. This means you need to be obsessed with it. That obsession will come across as rigorous discipline and your stakeholders will respect and appreciate you for it!
• Consider edge cases: Customers will use your product in all sorts of janky ways. So don’t just consider the happy path, consider edge cases for how your customer may use your product and how your product should respond. This is important so your UI/UX and dev teams can design and build out the journey for both the happy path and edge cases.
• Be prepared to answer questions: Use your empathy skills to think about possible questions your engineering teams may ask you. Put yourself in their shoes and ask yourself: “If I had to build this thing, what information would I need to know?”. From there you can identify gaps in your product requirements and be prepared to ask questions.
  
  

2. Make things EASIER or CLEARER

Your job doesn’t end after the planning phase of the software development lifecycle (if only!) In fact, it’s when your dev team gets into the implementation, testing, and releasing phases that things start getting messy and your support is needed the most.

The amount of control you have over your project declines as you move further into the software development lifecycle. Early on, your stakeholders support you during the planning phase by providing input and suggestions so you can solidify your vision. As ownership moves to your engineering team during the build phase and beyond, you support them by enabling them to do their jobs through making things easier or clearer.

Kirk Fernandes, CEO of Merit and product manager, said it best during our YouTube conversation: “When they talk to me, did I make things easier or clearer? Ideally one, even better, both. If I’m not, then I’m probably just making it harder for people to do their jobs.”

Approaching each interaction with this mindset is the trick to building trust and respect with your engineering team.

Making things easier means doing what you can to remove roadblocks and freeing up dev time to focus on coding and building. This could mean taking over customer tickets that don’t require dev input, taking up a role in the sprint process, or communicating with third parties, etc.

Making things clearer means removing confusion about product requirements, simplifying complex requirements, and using various communication aids to more succinctly get ideas across.

Do this:

• Ask this question often: After solo or team discussions, ask “What’s one thing I can do to make your job easier?”. I sat down with John Zilch, Sr. Director of product management at SugarCRM, during our YouTube conversation where he told me he took my advice and asked this question to his dev team. They told him there’s legacy code used by a handful of customers and because of that required engineers to still maintain it. Had he never asked, he would’ve never known this was a concern and that it was taking up precious dev time. He happily owned the deprecation process to move the last customers off the legacy code.
• Use less text and more visuals in your PRD: The human brain can process images up to 60,000 times faster than words. So when writing requirements, use visuals as much as possible and include text as supplementary context for further clarification. Examples of visual aids can be user flow diagrams, architecture diagrams, and quality UX mocks.
• Create if/else diagrams for complex logic: Ever find yourself spinning around in circles during conversations with engineering trying to figure out complex user journeys? I’ve definitely been there. Instead, bust out a diagramming tool like Figma and Miro to create if/else diagrams instead. The process of creating one will help you think through the complexity whilst the visual aid will align everyone on the same page.
  
  

3. Be flexible and pivot quickly

0.. that’s the number of projects I’ve worked on that’s gone 100% smoothly and as anticipated–and I’ve worked on a ton of projects. This is especially true for large projects. The more complex the project, the longer it takes to build and the territory comes with a great deal more risks and unknowns.

The truth is building software is hard. Like, really hard. It’s similar to building a house. You need a blueprint, a foundation, a structure, a design, a ton of people and a lot of patience. And if you think about it.. when has building a house ever gone as planned or finished on time?

Yep, that means even your most well-defined and thought-out product plans will fly out the window in the face of the unpredictable nature of software development. I’ve seen product managers (and even engineering managers) shoot themselves in the foot when they do things like mismanage deadlines by starting projects too late, get upset and blame devs for unforeseen issues, be strict and inflexible on requirements, and make promises to stakeholders that they can’t keep.

The key is to accept and plan early for things to not go as planned. When the inevitable inevitably happens, collaborate with your engineering team on the best options. It might mean engineering needs to come up with a different technical approach to the solution OR you may need to be flexible on the requirements and features. Don’t be afraid to push engineers for more innovative solutions and advocate for features you think are important, especially if you can justify why it’s absolutely critical. But the point here is to be flexible and ready to pivot in service of the bigger picture and collaboration.

Do this:

• Underpromise, overdeliver: Refrain from giving set dates for project completion. Instead, give ranges for possible project completion based on the best and worst case scenario. Outline the risks and unknowns involved so stakeholders have a realistic picture of the project. This will protect you and the team when things don’t go as planned.
• Break projects down as much as possible: The larger the project, the more complexity, unknown and risks you have to contend with. This is where the agile project management and “Minimal Lovable Product” comes in handy. Break your vision down into small, manageable projects and phases with clear deliverables, and their own project deadline. You’ll ship more value more often and keep the momentum going.
  
  

4. Improve your ability to communicate technically

Communication is important, especially in a role where you’re required to communicate frequently with engineers. But let’s face it, it’s also friggin’ hard. It’s even harder when you’re unable to understand engineers because they’re speaking what at times sound like gibberish.

But while difficult, keep in mind that you play a VITAL role on the team, even if you’re not in the trenches writing code every day. Much of your success comes down to how effectively you collaborate with your engineering team which requires having a solid grasp of technical fundamentals and being able to communicate using common jargon and terminologies.

This doesn’t mean you need to be able to code or have the same depth of technical knowledge as engineers. What you need to know and the detail to which you need to know it depends primarily on how technical your customer and product is.

For example, if you’re the project manager for a simple website, you can get away with understanding basic UX and web (HTML/CSS) principles. If you’re the product manager on a deeply technical product, say a database product, and your customers are developers themselves, you’ll really need to get into the nitty gritty of data implementation.

Side note: If you haven’t already, take Skiplevel’s 8-question technical mini-quiz to get a sense of gaps in your technical literacy (and don’t forget to share it with your friends and colleagues!)

With that being said, it’s completely within the realm of possibility to gain confidence in your technical abilities without becoming a dev yourself. To get you started, below is a list of technical areas you should focus on improving in.

• Client-side & Server-side (Frontend & Backend)
• APIs and their components
• Programming languages (Compiling)
• Cloud Computing (Scaling, Virtualization, Containerization)
• Architecture (Microservices & Monoliths)
• Data, Data Structures, Databases & Database Design
• Software Development Lifecycle (End-to-end process of building software)
• Deployments (CI/CD, pipelines)
  
  

DevOps

DevOps is short for Developer Operations and it's a software development methodology (fancy speak for way of working). The aim of the methodology is to bring together developers and IT operations teams (or sometimes called DevOps teams) so everyone works effectively, quickly, and with fewer errors. It's all about communication, collaboration, and automation.

When organizations adopt the DevOps methodology, they're adopting a culture, practices, and tools that streamlines the software development process by automating the software delivery pipeline. For example, an org with a DevOps culture and team might adopt things like:

• Continuous Integration and Continuous delivery: A software development practice for automating the software delivery (release) pipeline.
• Infrastructure as Code: Managing infrastructure in a declarative manner, using code and version control systems.
• Automated Testing: Automatic testing of all code using testing tools and frameworks.
• Continuous Monitoring: Setting up tools, frameworks, graphs and alerts to monitor software systems continuously.
• Containerization: Practice of packaging software code and its dependencies into lightweight, portable containers that run across different computing environments.
• etc..

Those are just a few examples. Doing devOps right is a very involved and complex process so it's common for tech companies to have dedicated devOps teams. Other large tech companies like Amazon will provide standardized devOps tools and guidelines to developers but ultimately development teams are responsible for their own devOps.

Sign up for the Skiplevel newsletter to get more content like this straight to your inbox.

If you like what you read, make sure to ❤ it, share it, and leave any thoughts in the comments!

Follow and subscribe for more technical tips!

Want to feel more confident in your technical skills?

Become more technical in just 5 weeks, without learning to code! We also train teams! Find out more at skiplevel.co/teams and book a call with me to get started.

Skiplevel is a program that helps product managers and teams become more technical without learning how to code.

Learn more about the Skiplevel program ⟶

Connect with Irene on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.