AMA: CookUnity VP Product & Design, David Cutler on Building a Product Management Team

Assuming this is an early stage company, the priority should be learning the basics of the business and building relationships with as many colleagues as possible. Use those learnings to construct a map of current products, problems and opportunities. Considering you are the first PM, any foundational product-related frameworks you put in place will be welcomed by most of your colleagues, so don't be afraid to suggest new ways of working. I'd also suggest reading some of the popular PM books which contain some really helpful tips and tactics: The Lean Product Playbook, Inspired, Product Management's Sacred Seven, The Product Book - How to become a great product manager. Good luck! 

I've noticed a trend in the tech industry for product organizations to follow a structure that Spotify helped craft over the years, in which a company is organized into business sub-orgs that roll up into their own respective product and engineering leads. And those leads oversee various squads that make up the product areas within that sub-org. At CookUnity we call the product areas "zones", in which a product lead exists to drive the product strategy and manage the PM team. In smaller companies (<500), those product leads are likely the direct leadership team for the Head of Product. You can follow this model at any size company, you'll just see a different scale of how many and how big the sub-orgs are.

I love this question because it's something I'm currently involved with at CookUnity. At a B2C company the marketing team is a Product Manager's best friend, especially in the early startup days. You can build the greatest product in the world but there are only so many Field of Dreams "if you build it they will come" success stories. You need someone out there telling your product's story and building awareness, hence the PM's need for a great relationship with the Marketing organization. Launching a new product, a new major feature release, or even a rebrand requires a collaborative dance with many different functions - especially Marketing and Engineering. Host a workshop with your marketing partners, make sure to draw lines in the sand with launch responsibilities and align on the timeline of events. A product launch can be thought of as a project, so you should treat it like one. Map out the technical and creative deliverables, document dependencies, assign owners to each, align on the timelines and get a thumbs up from everyone in the room before moving forward. Communication throughout is key! A product launch is supposed to be fun, exciting and many times the first touchpoint you have with new users - it's gotta be a smooth and memorable first experience. Product Launch KPIs should obviously be success oriented, it's about gaining reach: usage, new registrations, reactivations, engagement, etc. The marketing team may have their own metrics to reach eyeballs or ears (from my Spotify days), but if the eyeballs don't turn into new users and increased engagement then the mark was likely missed. 

All Product Managers need to be a sales person at different times in their career. As someone establishing a PM function for the first time, you'll be selling the vision of how an effective product manager will help the business and company achieve their goals. There's obviously at least one champion considering you got hired by somebody! But don't be surprised if some colleagues don't understand the need or value of a product manager, so this is the time to set expectations and build trusted relationships. The first step is learning as much as you can from the people around you. Try and become an expert in the business, where you can put yourself in their shoes when discussing needs and requirements. There's no exact playbook as the first PM, stay open minded and realize it may be a windy road to get where you need to be. Good luck!

In my experience a prioritization framework is foundational to establishing a great working relationship within your own team and stakeholders. I'd also argue that if executed well in the beginning, the framework may not change much regardless if you are the first or 10th PM at a company. In fact, it may be a bit more straightforward as a solo PM since the prioritized list of needs and deliverables is a direct negotiation between you, stakeholders and your delivery team(s). As the product organization grows you'll notice that blockers, dependencies and enablers exist within your own product peer group as much as your business and engineering partners. Product teams even become each others' stakeholders along the way. As the first PM, you should always establish ways of working and a framework for how the prioritization process will run: how you collect and understand requirements, validate impact, align on definitions of done, agree on and then communicate a prioritized delivery plan. I've used different versions of the RICE and MoSCOW methods in the past, which I suggest you look into. Don't skip out on doing things in a documented and structured way because you are riding solo, trust me it'll pay off in the end :) 

The first PM hired into a company, or in a division of a company, will usually be an individual who can wear different hats on any given day. (see one of my favorite product management graphics: https://medium.com/@productboard/the-many-hats-of-product-managers-4692aab2fff) The decision to grow and scale the PM team beyond your first product hire is made after discussing needs and opportunities with stakeholders, but also by gaining important insight from the existing PM that's been working in the trenches. When deciding who the next hires should be, I've found it helpful to first validate the problem and opportunity landscape and map out the pillars of your product strategy, e.g. systems, tools, applications, infrastructure, data, end user touchpoints, etc. It's obviously challenging to add too many people at once, so you'll have to prioritize the first couple hires and balance need, impact and culture. Remember that your PM team in the early days is a reflection of you as a leader, you are essentially scaling and complementing yourself to expand the team's overall strengths. I can't stress culture enough in the early stages of building a PM team. An unhealthy culture can make or break your ability to establish cross-functional trust which is super important from day 1.