HR Processes

Recruiting

In a previous essay, we described attributes of a world class PM. Among those attributes, technical acumen can be acquired through on-the-job experience or self-study, but most of the others — including the ability to think logically, empathize, comprehend a complex system, inspire teammates, put team before self, listen actively, and communicate clearly — seem to be more a product of nature than nurture. Put simply, some of us are intrinsically better suited than others to be engineers, designers, quarterbacks, or diplomats — and not many of us have the DNA to succeed in all of these roles at once.

Consequently, a process for recruiting world-class PMs must probe for these attributes. When hiring seasoned PMs, it’s important to establish that they have the “right stuff,” because it’s highly unlikely that a mid-career PM who lacks the innate abilities listed above can acquire them through additional work experience.

Deep, drawing on his experience with Google APMs, has also had success with screening individuals coming straight out of college for raw talent, then hiring those who pass muster into an associate PM program and molding them into world-class product managers through on-the-job training.

The APM approach probably only makes sense in late-stage startups or big tech companies. Early-stage startups have fewer product teams, and asking a rookie PM to lead one of them may be too risky – especially when the startup is still searching for product-market fit and relies on the good judgment of its PMs to determine whether, when, and how to pivot.

There are three qualities to look for in college grads.

Technical / Analytical Aptitude. This can be demonstrated through academic achievement in the hard sciences / engineering. However, Deep has hired cognitive psychology majors who’ve gone on to become stellar PMs. The key is to look beyond a candidate’s major for true aptitude. Promising candidates love to build things; their resumes will showcase software they’ve created and other side projects, lab work for professors, and campus organizations or startups they’ve launched while in college. They also take challenging CS and engineering courses, even if they choose not to major in those fields. Watch out for students who avoid those courses and do the bare minimum needed to major in a particular field. Many are embellishing their resumes without building strong technical skills.

Product Design Aptitude. At Google and LinkedIn, Deep asked college candidates to write a three page analysis of a consumer web product. The assignment was deliberately open-ended. It revealed a lot about the candidate’s motivations and abilities. Did they pick super popular products or relatively obscure ones? Did they choose to focus only on the business model, the technology, or the user experience — or a blend of all three? How did they find and use data? Did their argument demonstrate clarity of thought? And, importantly, did they stick to three pages?

Work Ethic / Intellectual Range. These attributes, which often go hand-in-hand, can be demonstrated by a candidate’s breadth of coursework, extra-curriculars, and outside interests. A PM is always overloaded. Prioritization and time management are important skills — and difficult to learn on the job. Similarly, a PM needs to synthesize ideas from many sources. Candidates with a singular focus can become experts in one area, but may have a difficult time taking on diverse projects, limiting their value to specialized roles.

With seasoned PM candidates, the interview process should include a few additional steps.

Can you talk about a poorly designed consumer product that's wildly popular?

Product Conversations. One of Deep’s favorite interview techniques is to ask a PM candidate about a consumer product that the candidate believes to be poorly designed. This reverses a question that many people prepare for: Talk about your favorite product. Asking about a poorly designed product helps the interviewer understand:

• How the candidate thinks about product design. What do they believe to be the characteristics of good and bad products?
• Whether the candidate is prone to reflection, curious, and intellectually flexible. It’s easy to claim to know why a product succeeds or fails in accordance with our beliefs. But an anomalous result – one that is contrary to beliefs — presents a learning opportunity.
• Whether the candidate really aims to understand a product’s user base. Far too many PMs build products to meet their own needs, failing to comprehend that they are not the target customer. Building a global product by necessity means replacing “I” with “the user.”

Mission Orientation. Great product leaders inspire others through a commitment to purpose and mission. They describe their commitment with great passion. Depending on a candidate's seniority, you should review their public presentations and talk to ex-colleagues to get a sense for what drives them. You might also invite them to give a talk about their favorite topic.

Continuous Learning. Is the candidate excited about trying out new products? Does she critically scrutinize product details? Did she pull apart her toys as a child? Does she brainstorm business models for the new restaurant she loves? Does she post reviews and improvement suggestions in online forums for her favorite services?

Onboarding

Getting the best people to come work for your team is only the first step. How a new PM is onboarded can have a big impact on how quickly and how much they contribute.

Deep personally onboarded every member of the LinkedIn product team — hundreds of new hires — via quarterly 90-minute orientation sessions. The meeting conveyed the team’s mission — build insanely brilliant and simple products that change peoples lives — LinkedIn product philosophy, and the principles for building successful consumer products. Deep discussed the new hires’ early experiences and assured them that they could talk to anyone on the product leadership team at any time. This set the tone for a culture that valued openness, meritocracy of ideas, and commitment to LinkedIn’s mission.

As part of onboarding, every product leader should create a “Getting Started Guide.” The guide should spell out job requirements, identify key colleagues, describe important product team meetings, and clarify first 30-60-90 day expectations for the individual. Drafting the guide forces a product leader to be clear about what it takes for a new PM to succeed.

Career Development

The energy expended in hiring great people can be wasted without appropriate career development programs and policies that keep the talent motivated and energized. We’ll briefly touch upon two somewhat less obvious topics here, while acknowledging that several other important topics warrant a product leader’s attention, including compensation philosophy, employee recognition, manager training, etc.

Career Ladders. Many rapidly scaling companies neglect this completely, with the assumption that growth will automatically bring bigger and better opportunities for star performers. While this is often true, having a documented career progression path gives managers and employees a common vocabulary and alleviates a lot of unexpressed angst. A sample career ladder that Deep and his colleagues developed at LinkedIn is shown below:

‍

(Semi-) Mandatory Rotations. When talent is scarce, managers can fall into the habit of treating their team members as prized possessions. To foster cross-team collaboration and expose less experienced team members to diverse products and management styles, it can be helpful to impose a 18-24 month rotation rule. For APMs hired straight out of college, it should be mandatory for them to work on two different teams over a 30-36 month period. For other PMs, rotation should be a privilege afforded only to good performers, so that managers are discouraged from doing a ‘lemon exchange.’

Can you move your organization from a mindset of ‘lemon’ exchanges?

The #1 reason for star attrition is unhappiness with a manager. Disaffected employees might stay with the company if they could find a different role (Gallup poll data). When done right, lateral opportunities can take the place of promotions and still create opportunities for employees to grow and learn valuable new skills.

Product Team Meetings

Product team meetings should be short, with a focused agenda.  Also, meetings should only be attended by those who can make a contribution to the discussion and decisions. In our experience, the somewhat common practice of joining a meeting for FYI purposes or to learn by being a ‘fly on the wall’ rarely yields enough benefit to warrant the costs: lost productivity and less effective meetings.

With that in mind, there are a few periodic meetings that provide product teams with light-weight structure that helps streamline workflows and promotes cross-team communication.

Product Team Check-In. This weekly meeting for each product team should be run by the team’s PM and attended by its tech lead, UX designer, data scientist, marketing manager and other appropriate functional leads. The purpose of the meeting is to do a progress check and triage any cross-functional issues. This is also the appropriate forum for communicating key product decisions and doing product demos for team feedback.

What are the 5 key questions to ask in every product review?

Product Reviews. The product leadership team, along with key engineering leaders and the product’s design leader and marketing leader should hold weekly reviews where one or more product teams present ideas for new products, new features, and other product improvements. Teams can also seek approval for upcoming product and feature launches and review results from recent  launches. For new product ideas, the team should address five key questions:

1. Who is the user?
2. What strong, unmet user need will the product fulfill? (aspirin vs. vitamin)
3. How will the product delight users? (UX design)
4. How will the user discover the product? (go-to-market)
5. How & why will the user share the product? (viral mechanisms)

Additional topics for the product review meeting could include internationalization/localization plans, KPIs, regulatory issues, etc. Since this is a large meeting, the ‘Native American talking circle’ format can keep the meeting running smoothly and secure feedback from key stakeholders.

For a more detailed discussion and some techniques for running product reviews, see Deep’s  Coda post on this topic.

Design Forum. This is a weekly meeting to critique designs for upcoming new products and features. Visuals are hung around the room and the designer solicits feedback. This is not a formal design review. To encourage ideation and elicit suggestions, the Forum is managed in a low-key way and all concerned should understand that the purpose is not to evaluate designers’ performance.

PM Meeting. This is a meeting of all PMs, held twice per quarter and led by the head of product. At the meeting, the product organization will discuss product priorities, case studies of recent launches, and critical upcoming launches. The group also will have a robust Q&A. The aim should be to foster open communication, team wide collaboration, sharing of best practices, and a common sense of purpose. The PM meeting also can provide a forum to detect and showcase emerging leadership talent.

Quarterly Calibration. The product leadership team should get together once a quarter to stack rank all product team members at the same level across the entire product organization. This calibrates the leaders on a common performance scale, gives visibility into stars on other teams, and encourages a discussion on possible rotation or promotion opportunities for these star performers. Is it time consuming? Yes. Is it worth it? Absolutely!

Organizing for (User) Success

When discussing product organization structures, the management maxim du jour is Conway’s Law, which holds that product designs mirror organization structures, because communication within a unit is easier than communication across units. It’s not hard to find evidence of Conway’s Law at work. Product designs will indeed differ if product teams are organized by feature vs. persona vs. conversion funnel stage.

Each approach will result in designs with strengths and weaknesses. For example, organizing by funnel stage – a common practice for growth teams – runs the risk of launching top-of-funnel initiatives that attract lots of new users who don’t fit into the product’s target customer segments. These new users are more likely to churn away quickly and they may actually have a negative lifetime value if they scare off attractive prospects with disparaging word-of-mouth.

“The first rule of organizational design is that all organizational designs are bad.”

So, Conway’s Law is a reality — but so is the need for product leaders to subdivide their organization for ease of management. Furthermore, all organization structures are temporary: they inevitably and appropriately must evolve along with a company’s capabilities and opportunities. Finally, all organization structures have shortcomings. As Ben Horowitz points out, “The first rule of organizational design is that all organizational designs are bad. With any design, you will optimize communication among some parts of the organization at the expense of others.”

Given all that, how should a product leader choose the best — or, equivalently, the least flawed — organization structure, at that moment in time, aiming to create products that delight users?  

There are essentially three ways to organize product teams, in order of increasing difficulty and rarity:

1. Give your best PMs more responsibility (aka “spoils to the victor”). There is nothing inherently wrong with talented PMs taking on more responsibility – it acknowledges their contributions, makes them happy, and sets a positive tone for the broader organization by showing that star performers will be rewarded with bigger roles.

Unfortunately, in some organizations, “spoils to the victor” can also lead to destructive political behavior, as PMs jockey for recognition and product leaders build and defend fiefdoms.

Even if political dysfunctions are avoided, over time, this approach can also create a hodge-podge portfolio for a rising product leader – one that inevitably leads to internal overlap, which in turn results in user confusion. Imagine a talented growth team leader who is given latitude to create new features across the full product suite, in addition to maximizing the monetization of existing features. It would be difficult to decide where growth initiatives stop and the core product initiatives begin. This leads us to org structure #2.

2. “Swim lanes.” Systems architects insist that every component should have non-overlapping functionality, with clear rules for data exchange between components. For Sam Clemens, this implies as little code-level interdependence between product teams as possible, meaning two teams should never edit the same software file. If they do, their releases could collide. Good version control (via GitHub etc.) can help reduce conflicts, but cannot fully prevent them. Clemens acknowledges a tradeoff with modularizing software in order to create distinct swim lanes: monolithic applications typically can be built more quickly, because specifying the interfaces between modules takes time. The goal, he says, should be to find a happy medium in deciding how far to push modularization.

When defining swim lanes, Clemens counsels against separating front- and back-end teams in an effort to ensure feature-level independence. He explains that teams simply cannot deliver a feature without coordinating front- and back-end efforts. The risk with staffing front- and back-end engineers on each of several feature teams, however, is creating a shared back-end that becomes a disjointed conglomeration of multiple teams’ contributions. The solution, according to Clemens, is an infrastructure platform team that specifies common architectural elements for its internal customers: the feature teams.

Amazon is a good example of the swim lane org structure with its famous ‘two-pizza’ teams and its long-standing reliance on a service-oriented architecture to dictate how the modular components of its internal systems work together. Two-pizza teams with well-defined metrics are great at ensuring fast, efficient code delivery, but like other swim lane organizational structures, they have two potential failure modes.

First, being singularly focused on your own component means you optimize that component and don’t care about the rest of the system. Consider the Amazon experience as a non-Prime member. You will get bombarded with solicitations to sign up for Prime. Clearly, the Prime signup team takes its goals very seriously.

Second, swim lanes can make it very difficult to design holistic user experiences. For that reason, as this Inc. article describes, Amazon is moving to the Single Threaded Leader (STL) approach for its large-scale initiatives like FBA – Fulfilled by Amazon—which provides a range of services to third-party sellers. This effectively creates a general manager-like structure with the leader being responsible for multiple teams collectively designing and building the end-to-end user experience. This is approach #3.

3. User-centered. User-centered organization structures can result in highly satisfied users, but they can be difficult to design and manage, because code is rarely written from a user persona’s perspective. Take the example of FBA:  its codebase overlaps with that of Amazon’s core business, that is, being a first-party seller. It makes sense for Amazon to re-use software modules which provide common functionality across both 1st- and 3rd-party experiences. However, it also makes sense for Amazon to have two different product teams in charge of these two very different customer experiences. Managing this tension makes user-centered org structures rare in technology companies.

User-centered structures have been successful in telcos. It turns out that the core technology offered by a telco – voice and internet connectivity — is broadly similar, whether offered to consumers vs. business customers, or to landline vs. mobile customers. Of course, the technology needs to be packaged and marketed differently for individual households, SME, and enterprise customers. Persona-driven product teams are responsible for such packaging in many telcos.

Maggie Crowley described how Drift, which offers a suite of software solutions for sales and marketing teams, reorganized its PMs, changing from “by product” reporting (#2), to “by persona” (#3), with the product PMs now reporting to newly-created VP positions that each had responsibility for one of three personas: marketing managers, sales managers, and enterprise company administrators of Drift services. These persona VPs each had counterparts from design and engineering who were responsible for the respective persona.

Maggie explained that initially structuring teams around products had made sense when Drift needed to launch lots of new products quickly. The reorganization was motivated by the chaotic workflow subsequently experienced by users as they moved from one Drift product to another. Maggie cited Conway’s Law as the culprit: each product team had taken its own approach to design. She recalled, “You could see the lines where design stopped between each individual product.” Beyond the resulting inconsistencies, no-one owned certain shared aspects of the user experience, such as application settings.

Maggie noted there was some risk of overlapping product development efforts with the new persona-based organization, because for large Drift customers, a marketing manager was often the enterprise administrator. Since they sometimes served the same user, the persona VPs had to agree on who would be responsible for which aspects of that user’s experience.

Drift’s monthly product review meetings for each persona, attended by the functional heads of all three personas (i.e., product, design and engineering), played an important role in negotiating who would do what — and also ensuring that when one group took the lead, the other groups’ requirements were considered. Maggie said, “Systems help—we used the Amazon service-oriented approach of turning some teams into clients of other teams’ services.  Meetings and rituals help, too.  But what really made the organization work was good communication between the leaders of each persona.”

When Deep led product at LinkedIn, his teams were organized around Growth, Engagement and Revenue — the company’s top three priorities. This worked for a while, until international growth also became a priority. Then, LinkedIn created an International product team, but this team had to cut across Growth, Engagement and Revenue. You can see how things get complicated quickly when you organize around more than one dimension.

Having tried all three approaches at various times during his LinkedIn tenure, Deep observes that as a product leader:

• You have to be cognizant of the pros and cons of your org structure and optimize it based on what you need at that moment.
• You should provide incentives to encourage all parts of your organization to cooperate and coordinate efforts.  In that spirit, Deep mandated that one of the three quarterly OKRs for everybody on his product leadership team was making one of their peers successful.

A product leader must take responsibility for aligning efforts in ways that ensure the best possible user experience. As Deep notes, no-one wakes up in the morning and says that they want to use LinkedIn that day. But they do say that they want to find a better job, or broaden their network, or learn a new professional skill – all of which can lead them to use LinkedIn.

Investing in the Future

Google’s first and still their most successful product (in terms of usage and revenue) is Search. However, Google also has other, wildly successful product offerings like Android, Chrome, Gmail, Maps, and YouTube. Similarly Facebook’s (now Meta) core social networking platform reaches over a billion users daily, but so do its WhatsApp and Instagram units. Amazon, Apple, and Microsoft have also successfully diversified their product lines.

This is not accidental. These tech giants all invest aggressively in innovation beyond their core business.

So, how should a product leader think about such investments?

Sergey Brin came up with the famous 70-20-10 principle at Google. Invest 70% of your resources in the core product, 20% in adjacencies and 10% in completely new endeavors. Google also instituted its famous 20%-time policy, which allowed employees to spend one day a week working on a passion project. Gmail was a notable outcome of 20%-time.

Other product leaders prefer different ratios. Selina Tobaccowala suggests spending 50% of product team time on product improvements, 25% on paying down technical debt and infrastructure projects; and 25% on new transformational ideas. For both Maggie Crowley and Sam Clemens, the ideal allocation is ⅓, ⅓, ⅓ for these priorities—but Crowley noted that the proportions will change based on the startup’s stage, with less investment in paying down technical debt during early stages. Clemens adds some cautionary notes:

• Product leaders should try to avoid sharp resource allocation swings toward any one priority. Such swings can cause problems in other areas to fester.
• With a CEO focused on sales, product, or engineering, one of the three priorities is likely to get too big an allocation over time, which will necessitate inefficient bursting with the other two priorities.
• A company can burst any one priority to 50% for a while with solid results, but not above that level, and allocations should never go below 10% for an extended period.

Whatever ratio you adopt, investing in the future is paramount to a tech company’s survival in a world where more than 95% of tech companies cease to exist independently within 20 years.

Scott Cook shared some takeaways on the organizational challenges that arise after making the high-level resource allocation decision. He categorizes product initiatives into four types:

1. Improving core/existing products
2. New features for core/existing products
3. New products adjacent to the core
4. Fundamentally new products, not closely related to the core

Scott notes that an organization’s natural tendency is to gravitate towards #2 while neglecting #1, for several reasons: 1) it’s exciting to build new features; 2) customers demand new features for existing products, and the organization is primed to respond to big customers’ demands; and 3) it’s easier to market new features than to promote the fact that an existing feature became 10% better (e.g., “Now our product isn’t so slow”).

While building new features is important, doing so at the expense of improving the core product may forfeit opportunities. Indeed, as Scott notes, Google still continues to spend an inordinate amount of resources on search — 18 years after its S-1 famously noted that “We do search.” In the same spirit, Toyota spent decades improving the quality of its cars, teaching the world the importance of “continuous improvement”. Jeff Wilke brought Toyota’s continuous improvement approach to Amazon, steadily improving delivery speed and reliability for 20 years.

According to Scott, a maniacal focus on the core product can be sustained by an inspiring vision of the product’s end state.

For example, Larry Page states that the search result page is actually a defect: the perfect search engine would get the user exactly what they want, when they want it.  In the same spirit, Toyota’s long range vision is to build cars that never break, and with no waste during production. Intuit’s vision for its tax software is to be trusted to do your taxes without wasting your time.

While it might seem paradoxical, a maniacal focus on the core enables the best companies to truly understand their users’ needs, look into the future, and invest in fundamentally new products that their users will love. To paraphrase Henry Ford, they can skip over the ‘faster horse’ (more features) and give their customers a car (true innovation).

Reflecting on fundamentally new products that are not closely related to a tech company’s core business (i.e., type #4), Scott says “virtually all are doomed to die due to an organizational immune response and organ rejection.” He notes that such products don’t help the core, but compete with it for capital and talented employees, engendering a backlash from the core teams (e.g., they might say “Who knows if that will work? Why are we wasting money on it? Give me the money”).

Fundamentally new products also conflict with management incentive systems because such systems focus on past financial performance. A type #4 product will incur lots of costs and little revenue in the near term. And, if the product ever does succeed, it will generally benefit its original product leader’s successor.

For these reasons, Scott believes that founder-led companies are more able and willing to invest in innovation beyond the core. Founders often make contrarian, future-looking bets and they are less susceptible to worries about job security, should these bets not pan out. However, of the five companies we mentioned in this section’s first paragraph, only one – Meta – is still founder-led. Nevertheless, all five continue to invest in the future and have created environments where innovators thrive. How?

First, they plant lots of seeds and share an understanding that innovations are typically driven by small, focused teams that in Scott’s words, have a ‘ground game’ and ‘air cover.’ For example, when Deb Liu initiated Facebook Marketplace, she started with four engineers. Deep started with the equivalent of five engineers (most of whom were using their 20% time) for Google Mobile. In both cases, this small team was sufficient to post some early wins (ground game) and had strong executive sponsorship (air cover). The small teams avoided the communications overhead and the expense of a large team, and eschewed mature product processes which would have slowed their progress. Companies like Apple and Amazon also innovate through stealth projects to avoid inflated expectations, especially from the press and capital markets.

Do you keep enough organizational “loose change” to promote innovation from within?

Second, innovative tech giants make hatching new ideas an integral part of their company culture. LinkedIn, for example, held quarterly hackathons and explicitly enabled winning teams to work on their ideas during a sabbatical from their ‘day jobs’ for a quarter or more, with agreed upon milestones and funding. As Scott Cook notes, “There is no shortage of current employees with ideas they are eager to pursue – they just need permission.” Deb Liu calls this ‘organizational loose change,’ and advises maintaining enough slack in the organization to absorb the periodic absence of small innovation teams.

At Zynga, Mark Pincus encouraged product teams to monitor and benchmark rivals to spot compelling new game mechanics. Mark built a drive for innovation into Zynga’s OKR system. He asserted that if less than 25% of a product’s engineering time was devoted to new ideas, that product would soon be redlining. Mark expected each team to generate at least one ‘bold beat’ per quarter– that is, a big, positive disruption in the gaming experience that was used by at least 25% of players and improved a key business metric by at least 10%.  This quest for ‘bold beats’ made sense in a hit-driven business like gaming where user attention spans are short and casual games lack inherent ‘stickiness.’

As noted above, efforts to innovate beyond the core may not be universally celebrated across an organization. There may be (valid) grumblings about why some people get to do cool new stuff while everyone else grinds away on existing products. When they gain traction, new businesses may compete with the core for capital, and may cause resentment by poaching resources from the core. Special incentive schemes for leaders of new initiatives can also be viewed as discriminatory, especially if core compensation is not at risk for the ‘intrapreneurs.’ Product leaders must be cognizant of these objections and preemptively address them.