Steven Sinofsky on Building Your Product Team

For our upcoming eBook on product leadership, we interviewed Steven Sinofsky, board partner at a16z and former president of Windows. Here, he shares his advice on scaling product groups and lessons learned as he rose from engineer to executive at Microsoft. 

Throughout Silicon Valley, Steven Sinofsky is known as one of product management’s earliest champions. In fact, he was at Microsoft when the company invented “v. 1.0” of the product manager career path.  

His career at Microsoft began in 1989 as a software design engineer and product lead. Twenty years later, he was President of the Windows Division. He’s seen it all, from when software required floppy disk drives to now, when it lives in the cloud.

Remember those boxes of floppy disks you’d buy at electronic stores back in the mid-eighties? Well, Steven was the one who ushered in Microsoft as the premier software brand of choice, bundling products like Excel, PowerPoint, and Word together into Microsoft Office. Before Microsoft brought the virtual office to market, however, the company realized it needed a new type of team member.

“Back when the original Excel team was building the tool for the first Macintosh for the initial version for Windows, there were only developers, testers, and marketers. A crucial piece of the puzzle was missing,” Steven says. “Microsoft needed a role that helped with making changes further upstream. That way, there would be people who could help facilitate changing the code, and minimize the big fights. There needed to be a point person who could help iterate the product, instead of having the marketers take on that responsibility, when they had the retail demand generation to worry about.”

What Microsoft lacked at this stage was someone who could both solve the conundrums of customer feedback and understand how that would impact the codebase. Since then, the role of a product manager (or program manager, as Microsoft calls it) has grown beyond the intricacies of code negotiations after collecting surveys or customer responses.

After beginning his career as a classic computer scientist, Steven became a program manager. He liked the idea of being the glue that held software together. Throughout his career, his professional mantra of “learning by shipping” has anchored his journey, guiding how he views product leadership. To Steven, product leadership is deeply personal, something that must scale within the product manager as the product itself scales.

“The most interesting thing about being a product manager and scaling over time is you,” he says. “You have to figure out a way to scale yourself.”

While managing your product and its roadmap, it’s easy to forget that your growth as a product leader is part of the process, too. There’s no “simple trick” to product leadership, but there are prerequisites. First, you have to consider your own development, and the paradigm you work within (and should it be challenged?); and second, you’ve got to let go in order to let your team grow and do the same.  

Steven wasn’t the first program manager at Microsoft. It was actually this guy named Jabe. Hired fresh out of college, Jabe joined the Seattle tech company and co-designed Excel, the first mass scale graphical interface product on a Mac, which launched in 1984. Then he stepped into program management.  

The first role of program manager led to a Microsoft (and now industry) standard: PMs must have a deep understanding of the product, and if the product is software, then technical acumen is a must.

“There’s a reason why the first product hires are usually people from within the company,” Steven says. “You want people who know the product – the code – very well. So well, in fact, that companies often have their own engineers turn into product people. For any PM, then and now, it’s important to know the code so when the engineer tells a product manager, ‘That’s not possible,’ a PM can say, ‘Of course it is, and here’s how.’”

This isn’t about bossing anyone around. In practice, a PM can use that knowledge to facilitate a discussion. Because when building the product, having technical chops is not only necessary to know if a vision is possible, but it’s also an access point to higher-level, strategic thinking.

“It’s important to see the argument being made,” Steven continues. “If you think that the argument is being made just because an engineer doesn’t want to do what’s requested, you have to actually address that, not fight over what can and cannot be literally done.

“It begins by understanding the root cause of what’s causing customer feedback or enthusiasm, and how and why customers feel empowered or disempowered by the product– and what you need to do about it,” says Steven.

Steven explains that when you’re a PM, there are two competing realities to the job – parsing what needs to be accomplished in order to increase user adoption, and then, getting your internal team motivated to build what needs to be built to accomplish said goal.

Skills in technology, user experience, and empathy (with internal team members and customers) are prerequisites that can be honed and trained. While building your expertise as a PM requires a mastery of all three areas, it’s important to remember that you’re never “done” building your skill set.

As a PM rises to the next leadership role (managing several product managers), they’ll have to learn another set of abilities as a people manager and relinquish their duties (despite the expertise) so others can take over. What may prove very difficult is to accept and remember that all instincts and abilities a PM developed as an individual aren’t automatically transferable with a new hire or direct report. You’re going to have to support your PMs so they can build their own expertise for themselves.

While they might seem similar, being a director of product isn’t just a step beyond being a product manager focused on a single product or feature. It requires different pattern-matching abilities and instincts.

“Once you get in a groove of being a product manager, it takes only a year or two before you have some pattern matching and familiarity,” he says. “You begin to see telltale signs. You begin to identify things more quickly, like whether a problem is about the product, time constraints, a person, or some other factor.” These prerequisites to the role end up feeling like they are a sixth, seventh, and eighth sense.

“There’re maybe a dozen of these product manager patterns,” he continued. “They keep repeating: Oh, this is the third-party extensibility dilemma. This is when it’s going to take more devs than we want. This is when our partners are creating a barrier, and we have to decide if we should compete with them or not. Patterns recur. When you’re at the helm of a product, it’s your job to identify them and problem-solve appropriately while at the same time recognizing when something isn’t fitting a single pattern.”

As the director who has been through the ringer before, you may be able to spot the patterns your PMs should take notice of. But it’s important to balance providing input and giving PMs the space to identify issues and solutions for themselves.

“When I joined the team, we were in the race to create Office for Windows. What that meant was bringing together three different products together – Excel, Word, and Powerpoint – that were often at odds with each other, even within the company. My job was creating one bundled product out of the three, but also navigating the different opinions of all the different teams.”

“For example, the Word team would go do a bunch of usability studies to gather ‘data,’” says Steven. (For today’s PMs who might’ve not even been born yet, these types of usability studies were done with no internet or networking.)

“A usability test,” he continued, “was watching how people used the product. One team would come back with the conclusion that after all these studies, the buttons should be 15 pixels by 15 pixels. Then, the Excel team would go do a test with a bunch of bankers and come back with the recommendation to make buttons 16 pixels by 16 pixels. There would be this nuclear armageddon over 15 or 16 pixels, and the PM’s job was to help negotiate and make the best decision for the Office suite of products.”

When you’re in the weeds of a major initiative like Office, a one-pixel difference to a button can seem like a make-or-break for the product. But in reality, it wasn’t ever about the dimensions. Rather, it was a larger conversation around what’s the best interface for our audience? What will help them do their jobs?

“There were a million of these kinds of debates,” Steven says. “Program management is where we resolve all those. Eventually, I learned that understanding what people are actually arguing about – the meta-level of the conversation – is the best entry point for problem solving.”

“As you move up the hierarchy of product management, and you’re the director of product managers, it’s much more difficult to be the one to identify the patterns and problem-solve,” he says. “You have to stop being the product manager or pattern manager, and start being the builder of a team.” And that’s a role that feels at odds with what product managers do: manage everything.

Hunter Walk, another prominent PM turned director of product, has championed the belief that you don’t need to move up the metaphorical corporate ladder if you want to progress in your product career. But if you do decide to go up to the next rung, there are some nuances to the role that are easy to miss.

It may feel counterintuitive to what you would expect – stepping into leadership requires you to let go of the reins. To someone who has successfully built his career scaling products, it may feel unsettling to let others figure out the nitty-gritty, and instead focus on the meta issues and how to keep everyone aligned with a greater vision.

“For me,” Steven says, “it would always come back to building a coherent team and a coherent product and a coherent value proposition.” To do that, he constructed the framework of a product organization versus focusing on the product itself.

For a dedicated product manager, giving up control of your product feels … wrong. But it’s a necessary (and inevitable) step as you switch from just growing the product to helping grow the company itself.

“As a product leader, it’s not necessarily your responsibility to build the product, but to be the creator of a framework for how decisions are going to get made,” Steven says. “In doing this, you are allowing people to discover the patterns on their own. Because these might not be patterns you thought of originally, and a new pattern might be on the verge of being created.”  

This is the PM’s nagging worry, that they won’t be able to see the forest for the trees, that they’ll be blind to an issue or to an opportunity. Hedging against “pattern blindness” by building a smart, capable team is the essence of disruption, and critical to staying competitive as a company grows. And you’ve got to resist the urge to copy and paste versions of yourself into the roles you relinquish as you are promoted. That’s not how anyone grows.  

“If you’re ‘the boss,’ it doesn’t behoove your team to just repeat your past decisions. Building a team isn’t about scaling more ‘you’s.’ It’s about empowering people to be self-sufficient, critical thinkers.” This is where “learning by shipping” applies to product leaders, even if they’re not touching product; it means preparing for change, not remaking a product org in your own image.

To Steven, this is how stepping into product leadership folds back into personal growth. Being a leader is not merely cloning your path or your methods, however “successful” they may have been. Nobody grows if that happens. In fact, it may put your company (and your product) at a strategic disadvantage.

“It’s tempting to want to save everybody the time and growing pains, and just tell them the answer. But there are two problems with that: One, on a personal level, that person misses out on the exploration and the learning; and two, your business might be the one that is undergoing a whole bunch of disruption, and so doing things the way you did them before might be the very thing that your competitors are hoping you’d do.”

“I remember we were starting to build out the first web-based services for Office. A lot of people said, ‘just buy more servers, and put more testers on it, and write more code.’ But what we did instead was add an operations team (now called DevOps) as a core discipline on the team. That way, we could bring the operational side of running web services to a software team. We couldn’t just put that on our testers.”

Disruption was on the horizon, and the Office team needed new people to problem solve.

“When scaling a product team,” he says. “You have to consider if you even have all the components to actually execute on your greater vision. Do you have the right team built for what you’ve set out to do? If you lack the experience or don’t see the path to success, how are you going to figure it out for yourself? Or, do you need to bring outside help to complement everyone’s efforts?”

This is another reason why nurturing a self-sufficient team is so critical: you can’t let them fall into the trap of not thinking and rethinking your processes when you’re no longer the day-to-day decision maker.

The process of building a coherent and cross-functional product organization can feel like a swirling mess when you’re the individual contributor witnessing the change afoot. However, as the director of product management, at the helm with a vision in sight, you’re moving the pieces around. You’re trying to figure how they fit together. You’re empowering others to make the best decisions and helping them see how, eventually, the sum of it all will become more than the parts.  

If those thoughts surface a twinge of discomfort, it may help to remember the old adage that  sometimes the only way forward is through. It can be lonely at the top of a product org. As Steven Sinofsky exemplifies in order to reach new heights, sometimes leaders need to break pre-accepted processes and structures to build anew.

“Part of growing up is knowing when your patterns are your weakness, and not your strength,” Steven says. But the growing pains are always worth the reward of innovation.

As its legacy shows, Microsoft, a company that evolved from floppy disks to cloud-based, browser services, underwent numerous cycles of breaking models and building anew. And Steven witnessed most of it all. Throughout his career of learning by shipping, Steven has grokked and practiced that breaking with your patterns can be the surest route to personal and professional growth for a career in product.

Stayed tuned for Part 2 in this series featuring Steven Sinofsky. In our next installment, he’ll share how the Office team used telemetry to set up their early analytics framework, along with more lessons from when Microsoft was scaling into the juggernaut it is today. Be sure to subscribe today, and get it in your inbox.