Rupali Jain

There are different types of updates that need to be communicated to the rest of the company and how those get communicated is different

• Vision/Roadmap: At least annually, live at the annual kickoff to the company.  A recording should be available at all times, as well as part of the sales enablement and onboarding materials.  A vision is high level and helps internal teams get excited about our direction and share that excitement with prospects and customers
• Major launches: Major launches typically are for a new product launch or new category of capabilities.  These involve the most work to communicate across the company and to customers including press releases, blog posts,  analyst updates, demos at conferences, webinars, internal enablement, customer references and more.
• Minor launches / Features: These should be grouped into coherent themes or focus areas to ensure the value of each feature is amplified.  A mistake that a lot of product teams make is to trickle out each feature individually without articulating a larger value proposition, which makes it difficult for the rest of the company, especially customer facing teams, to see the forest from the trees.  The onus is on the PM + PMM to articulate the value in a way that everyone in the company understands and can convey to customers and prospects.  These may not include all the activities listed for major launches but a subset
• Customer asks: In B2B companies, this is an important aspect of what customer facing teams look for from the PM.  The number of these tend to grow non linearly with the size of the PM team, and hence hard to stay on top of.  A good way is to set expectations for what set of these will get updated and at what frequency (e.g. top 50 updated every month etc..).  And it's also important to avoid focusing only on a small handful of the largest customers, but balance with the needs common across a larger base of customers.

While there are different specific metrics that marketing and product teams track for product launches, what's critical is the alignment between the two and agreement on the metrics to track prior to the launch.

Some examples of metrics tracked by each team:

• Product team: Satisfaction, usage by users and individual accounts, full funnel from a user trying the feature to actually using it
• Marketing team: % of reps enabled on the new product, leads generated, competitive win rate changes
• Metrics that require deep partnership: Number of customer stories/references for the capability

I'm going to suggest a few processes, but please do scale each process to the size of the organization. Treat your processes like you treat your product - establish 2-3 internal customer problems that are actually worth solving, and solve them with an MVP of a process and iterate as you learn - don't try to introduce everything at once.

• Quarterly priorities: Getting into the habit early of writing down the plan for the quarter is a good muscle to build early in establishing the PM discipline even with only a handful of PMs.  Focus on articulating the big bets for that quarter and the value delivered, written in language that peers and leaders can understand.  A key aspect of this is establishing OKRs each quarter to ensure alignment across the team, and cross functionally to drive product and business success.  Incidentally WorkBoard is an awesome tool to enable this
• Specs: Writing things down avoids late churn.  It allows articulating the why and the what for a feature.  Engineering can start work in parallel with some details getting ironed out (not a waterfall process), but the why and success metrics should be clear up front
• Design / Experience walkthroughs: Notice I'm not calling these reviews.  Reviews indicate a level of red-tape that is not necessary on smaller teams, but it's still critical to get feedback early from stakeholders, leaders and customers, so start doing design walkthroughs earlier rather than later, and you can avoid major churn later in the product development cycle

Team meeting: Reserve some time each week (PM only or PM+Design depending on team size) to look at the tactical work happening, what's coming up, concerns/help needed as well as to celebrate small and large achievements.  As PMs we often forget to celebrate the good, so make space for this.

The simple answer is to hire PMs :) .  That said, I'm assuming you are asking more of how to structure the team to scale to the needs of the organization as you hire

• Define the discipline: Hire PMs that align with your definition of product management. You'll also need to setup the discipline (see my answer on establishing the function)
• Enable each PM to own their area of the product or business end to end as you set up the team.  This is crucial.  Often this means aligning PMs to specific personas or specific products that your company has.  I personally tend to avoid aligning an organization to the technology pieces, instead focusing on the end to end experience across all layers of the stack, so the value delivered is clear.
• Keep the team at an appropriate size: I like to see PM teams run lean.  This forces good prioritization and focus and prevents slicing the areas too much.  That said, lean does not mean stretching PMs so thin that they have no time to think ahead and become only reactive.
• Don't forget about design: Also start investing in the design organization so you keep the PM and design teams in balance.

Whether you are the first hire or an early leadership hire that is trying to establish the product management function, the most important aspect is to show value.  Beyond that, there are a few critical aspects of setting up the function

• Align with the CEO/Leadership team: You hopefully established with the leadership team/CEO  how they define the role and what they wanted from you as the first PM hire before you took the job. If you didn’t, its still not too late. Do have a conversation around this quickly so you can get aligned. This is a necessary prerequisite to some of the other activities that you will do
• Define the function and its role: Explicitly define what the PM role does and does not cover.  Having a definition in place will prevent the role from turning into a "glue" function i.e. pick up the slack that is not covered by other roles.  Establish that the role of the PM is to define the why and the what, and the how will be in collaboration with engineering.
• Create the criteria for product success: This may often be defined as the northstar metric.  Also show progress towards this and clearly show the correlation between the criteria and the overall business.
• Establish a clear connection to the customer: As you define the role, establish a way to talk with customers to start getting signal.  Nothing gives you and other PMs on the team more credibility than using examples of customers that would use your features or are requesting them (this applies primarily in B2B)
• Use Wins to establish value of the role with stakeholders and peers: Don't underestimate that establishing the role will take time.  Ensure you spend time with stakeholders, your peers and the broader organization.  Instead of just focusing on defining the role with them, use every "win" that you have to establish the value the role creates.

And finally, build out your team ensuring that you focus on hiring PMs that excel at the role as you have defined it and enable them to succeed!