Melissa Ushakov

* Soft skill: Great product managers can seamlessly adjust their communication to match their audience. As a product manager, you'll speak with people in different roles and varying levels of expertise in your subject area. It is essential that you can communicate your ideas and exchange information with everyone! I really love the perspective shared by Camilla Boyer in a recent talk at GitLab about communicating with emotional intelligence https://www.youtube.com/watch?v=3pZoNORrDjU. Product managers should approach conversations with the mindset of providing the information their audience needs instead of focusing on what they need to say. * Hard skill: Iteration is one of the hardest things to master, but it is essential for providing value quickly and getting feedback to improve your product. GitLab has great resources to help improve this skill. Check them out https://about.gitlab.com/handbook/values/#iteration! One thing that has really helped me improve my iteration skills is to think of my product as ever-evolving and that what we release is not the final version. If a set of changes are an improvement to the current experience and there's a clear roadmap to build upon that experience, then we should release it even if we are not done! 

I'm a Group Manager of Product at GitLab https://about.gitlab.com/job-families/product/product-management-leadership/#group-manager-product-gmp. I am a manager for the Product Managers for the Plan stage at GitLab. Each product manager on my team has engineering, UX, and quality counterparts that they work with to build their products. I also have leadership counterparts in Design, UX, and Quality. We all work together to steer the direction of a collection of teams. You can see all the details in our GitLab handbook https://about.gitlab.com/handbook/product/categories/#plan-stage . 

Developers on the team will generally have a sense of the market since the products we build target them as a persona, especially if you're dogfooding your product. It's important to validate problems and solutions with customers to ensure that we're building a product that aligns with market needs, not just our own. I go into how to do that in another one of my answers. Product Managers on the team will build a complete picture of product priorities by talking to a diverse set of end users and analyzing the market. PMs should share insights with the team and give enough context in prioritization discussions to clarify why decisions are made. 

As a Product Manager, you need deep knowledge of the personas you serve. To build great products for developers, you don't need to be a developer, but you need to understand their challenges, motivations, and day-to-day work. I encourage product managers to use the products they build so that they truly understand their users' experience. This means that product managers for developer products need to be more familiar with software than product managers for other types of products.

I think that the whole team should strive to build a product that end users love. I love when there's passion on the team and ideas about what to build. When you are building a product for a persona that is close to you, it's important to gather data from end users to ensure that you have a complete picture of their needs. This generally comes in two forms: Problem Validation: Identifying your end users' pain points. This can also be confirming of a problem hypothesis. https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation Solution Validation: Ensuring that the solution will meet end users' needs. https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation Sharing customer learnings with your team goes a long way in helping get alignment about what you are doing and why. I like to post summaries of my findings on our team Slack channel and document my detailed findings in places that are accessible to the whole team. Ultimately, product managers are responsible for the product roadmap, but collaboration is essential! Some of the best ideas for features I've worked on have come from other team members.

One common mistake I have seen is having a monetization model that does not scale. Services and customization on top of open-source software will only scale as much as your workforce can. Having paid features on top of open source software and a tie ring philosophy that can be easily explained is esssential. A tiering strategy for features based on buyers has worked well for GitLab. The free tier targets individual contributors, and other levels target enterprises. You can read more about it here https://about.gitlab.com/company/pricing/#three-tiers. This video where the GitLab CEO walks through a monetization strategy with a startup is also helpful https://www.youtube.com/watch?v=UbMkw6GD7TQ .

There are three key aspects of this: * Consistency - In large companies, APIs are maintained by many teams. Ensuring consistency across endpoints is essential to a great end-user experience. It's hard for when users when switching endpoints changes the format of standard fields like timestamps and other audit fields. The first step is to have agreed-upon technology and conventions. Then you can start enforcing the standards during code reviews and with your automated tests. * Documentation - Complete documentation is table-stakes to the self-service experience. Standards like OpenAPI https://www.openapis.org/ help create documentation automatically, increasing efficiency and accuracy. * Discoverability - The ideal experience is that your users don't need to consult the documentation. Your API should give end-users ways to learn about the functionality directly from the API. You can read about how that can be achieved in this article https://thenewstack.io/the-state-of-introspection-for-rest-and-graphql-apis/ .

One question I love to ask is: "Tell me about a time when a conversation with a customer made you realize that your product direction was wrong." I have heard so many great stories about dispelling assumptions by talking to customers. One of my favorite stories was when a PM did generative research about the biggest problems their users faced with their product. They found that the feature that they were planning to spend the greater part of their upcoming capacity on was not mentioned at all! When the PM brought up the feature idea, users communicated that this feature was by no means at the top of their list. This PM found a whole new set of problems to solve that would be of higher value. 

I've always been drawn to tools that help teams collaborate. I love the feeling of knowing that I made a team's day-to-day work easier, more enjoyable and gave them more time to spend building great products. In almost all my jobs, I became an admin for our DevOps tools, spent time working with teams to optimize the configuration, and was part of rolling out standards. I sought out a career in the DevOps tooling space so that I could pursue my passion and have a bigger impact. 

Contributing myself and supporting my team can be at odds with each other. Coaching and supporting my team is always my number one priority. There are times when I simply need to say no and deprioritize things to ensure I have enough time to support my team. It's important to have open communication with my team about what I am working on, and it's something we talk about during our weekly one on ones. Sometimes someone on my team is interested in something that's on my plate, and they volunteer to help. For example, I was thinking about writing a blog, and when discussing the idea, someone on my team volunteered to write it. When I find my plate getting overloaded, I consider whether this would be a good opportunity and is aligned with the career goals of the PMs on my team. I recently volunteered to help with some UX research that I later found I don't have time for it anymore. This aligns with a growth area for another PM team on my team, so I brought it up to them, and they were excited about taking that on.