All related (6)
Rupali Jain
Chief Product Officer, WorkBoardFebruary 27

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.

Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 2

Expanding the team from 1 to multiple people comes with a set of pitfalls that I’ve learned the hard way. And many other factors such as Org culture, line of business, product lifecycle etc, have a telling effect on the type of pitfalls you’ll encounter, so take this with a grain of salt. Here are a few things worth considering -

  • N degrees of separation: The larger your org grows, more layered your teams are (typically). Ensuring that you and everyone on the team feel connected to each other in a meaningful way is super critical. Here are a few tactical things you could do -
    • Regular team meetings for sharing broader context
    • Async modes of information dissemination (via ‘Top of mind’ type notes, ‘bite sized’ videos etc)
    • Skip level 1:1s at a certain cadence to get a pulse on the ground (and also to get feedback about you)
  • Curating culture: I recently read somewhere that team culture is nothing but ‘Behaviors you reward and behaviors you punish’. As your team grows you’d want to ensure that the culture or identity of your team is well understood and reinforced regularly. Coaching your managers/leads on that front should be top priority because they ultimately play a key role in sustaining that culture.
  • Delegating decision making: When you manage a small team, typically a lot of the decision making (and tie breaking in terms of conflicts) comes to you. As your team grows there might be a tendency to follow the same approach which you should discourage. Empower your sub-teams and sub-team leads to take ownership. Have a clear sense of when you want to get involved. Here is the framework I use:
    • Just inform me as FYI for X set of topics
    • Seek opinion from me for Y set of topics.
    • I’d like to be the approver/decision maker for Z set of topics (ideally this is a very narrow list)
  • Goal mapping: As the org/team grows ensuring everyone’s work ladders up the org level goals is of paramount importance. In our roadmap templates we have a way to ‘map’ each team's goals to the org level goals. The teams articulate how their deliverable move the needle on the org level top line goals.
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly Microsoft
“Change is the only constant” is a cliched phrase in the industry but the reality is not far off in many lines of businesses. At Meta we often get to work with the best available information in hand and not afraid of pivoting when that information changes. That comes with a degree of ambiguity, churn and sometimes loss of motivation for the teams involved. As a leader, my role is to ensure the teams have a strong understanding of the ‘why’ and when priorities change, again communicating the ‘why’ with full transparency. I then empower the teams to drive towards subsequent outcomes which cou...
Rupali Jain
Chief Product Officer, WorkBoard
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 c...
Zeeshan Qamruddin
Director of Product Management, Fintech, Hubspot | Formerly Segment, WeWork, Airbnb
At the company level, there are a few different methods of communications to keep everyone abreast of updates: 1. Product Notification emails (Ad Hoc) - These emails have a set template and allow product teams from around the company to share updates to their areas in a digestable format as major features go out of the door.  2. Product Newsletter emails (Weekly) - The weekly newsletter summarized major product updates and initiatives to all product team members.  3. Quartery Business Review meetings (Quarterly) - These larger meetings gather key parts of the business to...
David Cutler
VP Product, CookUnity
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.  ...