Todd Jackson was in a small conference room with a handful of designers, engineers and Mark Zuckerberg. The topic at hand: the Facebook News Feed redesign, intended to declutter the Facebook experience and make it even more engaging. They went over the latest mockups, discussing photo sizes, text density, and the redesigned website navigation. Then they honed in on one seemingly minor point: turning people’s names from blue to black. Jackson, the product manager in the room, knew this was more complicated than one might think.
In fact, Zuckerberg had a simple philosophical stance on the matter — that people’s names should remain bold and blue because people are at the center of Facebook. The people are what all the content pivots around, and they should stand out, he said. Jackson’s team had a different contention: in order to more deeply engage its audience, Facebook needed to evolve to showcase content first.
In this conversation, Jackson had to wear multiple hats. He needed to absorb Zuckerberg’s argument. He needed to advocate for his designers and engineers. And he needed to think through all of the other pieces and people these changes might touch: internal user operations, external news publishers — not to mention the site’s users. This usually boils down to two sides of the same fence: founders or executives pushing for product changes, and the engineers and designers trying to build them.
Such is the plight of the product manager. And Jackson knows better than most. As a PM on Gmail during his time at Google, and on News Feed at Facebook — and now as the CEO of his own, newly-launched Android startup, Cover — he’s worked through tough problems with some of tech’s luminaries. If anyone knows how to balance multiple interests, it’s him.
Backed by this experience, Jackson has devised very specific hacks that product managers can use to manage people and expectations effectively. Starting with the birthplace (and chopping block) of new product features, he highlights meetings with founders and cross-functional stakeholders as a critical part of the job.
Product Managing Founder Meetings
There’s a reason why product managers lead preparation for these meetings — and why you often see their names in the press talking about new products. They’re the main communication hub for their project and all the people working on it.
“It’s really the PM’s role to prep for these meetings — you want the engineers to be too busy writing code,” Jackson says. “At the same time, you need to represent your team 100%. This means sharing your slides or your outline prior to the meeting so they’re informed and feel good about everything, even if it’s just over email.”
Having the team trust you to speak on their behalf is rule number one.
Jackson has several other rules for these situations — best practices that span industries for PMs:
- Always know the current status and context: You should always know where key people in the company stand on what’s important and why. You should also know what’s going on with the competition.
- Jump from small details to big picture: “You should be able to articulate the highest level strategy behind a product but also be ready to explain why a particular UI element is placed the way it is.”
- Have moxie but don’t self-promote: Compliments should always go to the team. Credit should be handed out freely and generously. Success belongs to the team but failures belong to you.
- Be a master of influence, not authority: Obviously, you have no authority over the founders or cross-functional stakeholders you’re presenting to — you also probably don’t have authority over the engineers you work with. You have to be a good communicator and make things easy for people. “Fill in the whitespace everywhere for everyone,” Jackson says. “QA a new feature, write the first blog post, make mock-ups your designers might think are amateur but will give them inspiration. Do the boring stuff that makes a difference and moves things forward.”
- Get decisions made: You may not be the decider at the table, but it’s your responsibility to make sure a decision gets made. Half of this is getting the right information in front of them. The other half is getting the right people behind them.
Getting even more granular, Jackson recommends keeping presentations short, 10 to 15 slides max. Most of the time, they can just be sent to the team over email unless there’s something really controversial. You should try to eliminate as many meetings as you can.
Distilling a product review down to 10 slides can be a challenge, but it's an excellent forcing function to provide a full but simple snapshot of where your project is at. “These meetings force you to put together a story of what’s going on. It gives everyone on the team a sense of the bigger picture, and the goals you’re tracking against, and the resources you need to get the job done.”
Making progress with any particular stakeholder is all about knowing what’s important to them, Jackson says. Understanding their values is like being able to speak different languages. A founder has completely different concerns from someone in operations or marketing — even at an early stage. “The points that matter most will be different for each person. Founders like Larry [Page] or Zuck want to know what is the user experience for product X? Why is it important strategically? Ops and legal want to know how hard it will be to support product X. How many customer service requests will they get as a result? Knowing and speaking directly to your audience is critical.”
For Jackson, this “multi-lingual” approach comes down to empathy — something that not too many product managers may recognize, but vital all the same. “As a product manager you have to have empathy for many different points of view. You have to be that person that can communicate with anyone while also driving conversations forward.”
At the same time, you want to make sure to reserve enough time in a meeting for open discussion and to field questions and concerns, Jackson adds. “Often, you’ll get interrupted right away, and you need to be willing to engage whoever it is in open-ended debate. This is where a lot of good questions or ideas come up,” he says. But, because founders are thinking so big, this also leaves you vulnerable to derailments.
During his time at Google, Jackson found himself in a review of a new UI that would make Gmail, Calendar and Docs all searchable from the same place. “Larry suggested we go way beyond this. His idea was to ‘just OCR’ the entire computer screen continuously so that you could easily search and find anything you had ever seen on your computer. That’s great. But that technology had nothing to do with the technology we were building and would be about ten times as difficult. But for Larry, it was the same conversation. On one hand, this was beyond the scope of what our team could tackle. On the other hand, it’s the reason why the company is doing amazing ambitious things like driverless cars.”
Jackson’s recommendation: Let yourself get derailed, but not too much. “If they give specific suggestions that you don’t agree with or that sound random, always strive to understand the spirit of the request. Sometimes you might disagree strongly with the specifics, but you really do agree on the high-level goals. Also, founders challenging your team to think bigger will help you achieve better results in the long run.”
If derailments crystallize into serious decisions, Jackson recommends pinning founders down to brass tacks. “Ask them directly: ‘So is that a decision?’” he says. “Then make your next actions clear: ‘We’ll follow up on that point and come back to you.’”
More importantly, only agree to decisions in a meeting that you’ve had a chance to think through and feel confident in your team’s ability to execute. “Usually if a founder has a brand new idea in a meeting, everyone will nod their heads. So then you agree to it too hastily and later you realize there’s some big ‘gotcha’ or it wasn’t as high-impact as it seemed at the time. So the better course of action is to let them know which big ideas you agree with, but leave yourself some wiggle room on specifics.”
In 2007, when Jackson first joined the Gmail team, it was the first email service provider to offer IMAP support for free (aside from Netscape 10 years prior). Yahoo, Hotmail and the others were charging for it as part of their premium plans. Google’s executive team had questions about how to proceed. At the same time, Gmail’s lead engineers were impressed by the announcement of the iPhone and wanted the product’s users to have a great experience on the platform. IMAP would let users sync all their actions across their phones and desktops, applying labels, stars and archiving messages — so it was central to the strategy.
“But we still didn’t know if we could make it free,” Jackson says. “That would essentially enable Gmail users to use the service without seeing any ads, and therefore we couldn’t recoup any revenue to pay for their storage costs. But Larry and Sergey — basically on intuition — said it should be free. Their reasoning was that if people liked Gmail on their phones, they would use the service more overall, and there would be a lot more valuable side effects to people loving their Gmail accounts.”
Jackson and his team did the research, and unsurprisingly the cost of this strategy would be substantial. But Brin and Page said “Let’s do it” anyway. Now, down the line, with single sign-on to all Google apps playing such a pivotal role, it was clearly the right move. The decision even pushed competing email services to offer IMAP for free and increase their storage limits. That’s a pretty solid win.
The moral for product managers is to be able to very finely distinguish between the things leadership cares about versus lower priorities or random ideas. People won’t come out and tell you the difference explicitly. “It could be something technical, or something totally different about PR or sales. As a PM, you need to be able to jump into any of that stuff, but often the best thing you can do is say ‘Give me some time to think about it’ and then get back to them later offline.”
To make stakeholders feel heard, Jackson recommends repeating the most important action items, decisions and follow-up promises at the end of a meeting.
You can't leave any chance for misunderstanding, or for even one person to walk away from a meeting with different conclusions.
A lot of product managers can get the life force sucked out of them by these type of reviews. They come away, crushed under a load of new action items that they somehow have to coherently relay to the team. But Jackson advises a shift in perspective. “Use the decisions made by founders to get things done,” he says. “Use them to motivate your team and the teams you need to support you. Employees are usually at a company because they respect the founder.”
For all these reasons, positively relaying what happened in product review meetings, and very closely tying future actions to founder asks is a great way to get people aligned.
Motivating Your Team
If fielding founder requests and concerns is a major part of a PM’s job, an even bigger part is motivating and coordinating designers and engineers to reach company goals. This comes with its own share of personalities, land mines and mind tricks. But if there’s one overarching piece of advice Jackson has up his sleeve it’s this:
To inspire a team, tell a good story. Then break it down into an execution plan.
A huge fan of inspirational mockups, and an adept user of Photoshop as a result, Jackson can’t emphasize enough how important it is to show your team what needs to be — or ideally what could be done — before beating the drum of productivity. PMs may be measured and rated based on their teams’ progress and speed, but there are good and bad ways to reach the same end.
“I love creating mockups and working with designers to show what things could look like. And then you start telling a narrative. Like when we were working on the News Feed redesign, it was: ‘News Feed has gotten cluttered. It’s been the same way for years. People scroll down and once they hit stories they’ve seen they close Facebook and do something else. Wouldn’t it be amazing if News Feed looked like this?’ That’s when you show the mockups and say, ‘There’s so much awesome content being posted by the pages you follow, links your friends have shared, photos your friends have liked. What if we made these look so good that people looked at twice as many stories a day? If this happened, they would spend twice as much time on the site. Other people would get twice as many likes, and we’d get twice the revenue.’ That’s a story a team can understand and rally behind.”
Essentially, it’s a pitch. You’re trying to get people to see things from your point of view by saying, “This is awesome. This is something users are going to love. This is something your friends and family are going to love. And it’s going to be good for the company.”
While this tactic works differently on everyone, Jackson has found it to be especially motivating for engineers who may have a more siloed view of a project. “I think engineers get excited about the future. They become engineers because they want to help create the future. So show them what it could look like. Get them excited about what it could look like. If they’re excited, they’re going to work hard to make things happen.”
Of course, this is the stuff of big vision. So how do you keep people churning when you break things into smaller and smaller chunks? Jackson has some very specific advice in this area:
- Milestones: Work with short milestones, ideally two weeks. It’s impossible for an engineering team to have a detailed six-month roadmap. It will never be accurate. In two weeks, people understand what they can get done this week and next week, and they can keep it all in their head. It’s also enough time to make substantial, visible progress. “On Gmail, we would always have a Friday meeting at the end of two weeks so people could show off what they'd done, and you wouldn’t believe how much was possible in two weeks. It has a natural cadence to it."
- Keep meetings short and focused on demos: There are two types of meetings — decision-making meetings and status update meetings. Both should be kept short and only include the relevant people. Status meetings should be based around what people have accomplished. “Demos are the best. Culturally, you should set a low bar for demos not needing to be super polished so people aren’t afraid to show their stuff early. Applaud each other. Create an environment where engineers can’t wait to show each other what they’ve built, and they leave eager to go back to it.”
- Be a shit umbrella, not a shit funnel: You have to be protective of your time and your team’s time. As a PM, you’re in meetings all the time where executives are very blunt and say that things aren’t working at all and the team needs to do a way better job at X, Y or Z. “You have to develop thick skin, and then you need to learn how to translate all of the criticism you hear into something motivating."
- Think through the edge cases: Engineers usually take it upon themselves to think through all the edge cases to any scenario, but they really appreciate it when PMs and designers beat them to it. “Engineers want to be inspired by the vision, see a plan for the tactics, and then see how the latter will add up to the former with all things considered.”
The great thing about designers and engineers working in proximity is that they can keep each other motivated and productive. Engineers are galvanized by the images and ideas the designers churn out, and the designers are re-inspired when they see their creations come to life. “You want designers and engineers to really value working shoulder to shoulder,” Jackson says. “Both groups are motivated by the high-level goals of a new product or feature. You want them to iterate on designs until they manifest those goals.”
For high-velocity productivity, Jackson recommends pairing designers with engineers who vocally value design. There is nothing a designer likes better than a fast engineer who nails the details on the first pass. They’ll want to work even harder to please this person.
He witnessed this phenomenon firsthand while working on Facebook Groups for Schools. That project started off with just one designer and two engineers. They set up a mini war room, choosing to launch on college campuses one by one. They literally all sat back to back so they could see what each other was doing, and ask questions accordingly. On a whiteboard, they devoted one side to high level goals and the other to incremental tactics that would get them there. With a short iteration cycle and tangible milestones, they were fueled by accomplishment every week.
“Every week the product got better because we could see what had worked and what didn’t, and make the requisite change before we launched at a new school,” Jackson says. “We saw that there was limited pickup and no one was clicking that big button that said ‘Facebook Groups is now at your school.’ So we decided to ask them questions, like what dorm they were in or what activities they were a part of, and suddenly everyone was joining these campus groups. It’s something we arrived at because the four of us worked so closely and could just turn around and talk to each other.”
When engineers are motivated, even if they run into something they don't know how to do, they'll say, 'We can totally figure this out. We've got this.
As a product manager, you can further capitalize on this energy by rewarding the engineers who do end up solving the toughest problems. “You wait for the next Friday meeting to roll around and ask one of the engineers who knocked something out to demo it to the team. You say ‘Look what this guy did. He totally figured out that thing we were stuck on all last week.’ Sometimes you have to encourage them to do it, but overall it promotes a great feeling.”
This is also the logic behind ‘Eating Your Own Dogfood’ as Google has monikered it. Big technology companies are now known for deploying new products and features internally before testing them or releasing them to the public. It gives product managers and engineers a chance to work out the bugs and safely gather feedback. But it also serves an even more important function according to Jackson: “It gives them a glimpse of what their friends and family will see, and one of the greatest joys of being a product manager or an engineer is being that guy who helped build something everyone you know uses and loves.”
When a product is released to the team working on it, one engineer might break something that another engineer will immediately recognize and fix. At both Google and Facebook, there were systems set up so that everyone could see the product at each stage of deployment. At a certain point, this repair-and-innovate cycle turns into pride for the product and wanting it to be perfect, Jackson says. When you feel good about something you use every day, you feel that much better about exposing it to outside users. "To be recognized by their peers or by people they respect — that's probably the main thing that drives people."
This sounds all well and good, but in most cases, it needs to be carefully choreographed by PMs who need to continuously make sure that people are driven, have the tools they need, and aren’t bottlenecked by teammates or phases of the project. This demands an acute sense of anticipation — especially when you are the bottleneck.
“So many times as a PM, I would think ‘Oh god, this engineer could totally be building this thing except they’re waiting on me for mockups and specs,’" Jackson says. "You have to constantly determine who you are blocking. I think that’s a totally valid way for a PM to prioritize their time. Even if you aren’t bottlenecking someone now, in a week you will be."
I don't see the PM's job as having all the product ideas. I see it as keeping the engineering and design teams firing on all cylinders.
There are several tools — quite analog in some cases — that Jackson has relied on to keep this pace humming. It starts with his assertion: “You need to be organized or you’re not a good PM. Period.”
- You need a team task list that transcends a simple bug system. It should be big, ideally on a whiteboard that everyone can see and consult.
- You have to be a ninja-quality expert at email. PMs at Facebook and Google regularly receive over 500 pieces of email a day but being responsive is mission critical. “It’s okay if engineers and designers are bad at email, but PMs absolutely cannot be bad at email. You have to get back to people right away.”
- Maintain your own task list and organize it into sub-lists: today, this week, someday and maybe. Never silently drop a task and don’t tolerate silent drops from the people on your team.
The Hallmarks of a Great PM
So how do you know if you’re doing a good job? After all, when you really look at what’s being decided on one end and produced on the other, it might look like a PM is doing nothing at all. In most cases, this invisibility is a good sign. There are a few other tells.
“A big one is that the founders ping you directly without CC’ing other people. They just trust you to follow through and they know your team trusts you to be a good channel of information back and forth,” Jackson says. Communication skills are paramount. “One sign of a great PM is that other people get quiet when they start talking. A lot of PMs talk too much and spend time on things that aren’t important until people start tuning them out. If you see a PM talking and everyone else stops talking and listens, you know they are pretty good.”
You're also a good PM if your absence is noticed by the best engineers on your team. "You want them to ask 'What would that PM do or say if she was here?' You want the best people to value your opinion that much and know you have the technical prowess to meaningfully contribute."
Lastly, a great PM should have strong product vision. This isn’t an absolute requirement, Jackson admits. Organization, infrastructure and a positive attitude can get you pretty far. But to get to that next level, you need to have gut-level intuition about what makes products good or bad.
“At every company, there is a collection of people who are known for their excellent product sense — usually it’s a founder, a senior engineer, a director of product, depending on the size of the company,” he says. “But when you see a PM pushing for a certain product decision and holding her own in discussions with these people, you can assume she’s got admirable product chops.”
Life After Product Management
Today, Jackson is running his own startup, an Android app called Cover that makes sure the right apps appear on your lockscreen at the right time based on your context. Essentially, if you’re at work, apps like Dropbox and your calendar will pop up first. If you’re in the car, then maps and music might be at the top. In many ways, co-founding the company has been completely new for Jackson — but in many more ways it’s familiar territory.
His spokesperson skills have translated seamlessly. He’s gone from pitching products and features to internal stakeholders to making the case for Cover to VCs, angels, and potential hires.
While there are elements that are more foreign — attracting PR from scratch, adapting to the sheer amount of time you need to spend recruiting — Jackson argues that product management is a great setup for striking out on your own.
“Founding a startup forces you to look for under-explored markets. You’re constantly seeking a new idea that users will love,” he says. “And as a founder, you can fully determine your own budget and how to allocate resources. You don’t have to keep one eye focused on existing business units or company priorities and how your project might impact them. But without a doubt, my PM experience made it possible for me and my co-founders to arrive at and launch Cover.”