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'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. 

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.

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. 

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 . 

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/ .