Ken Norton’s Discipline of No

“People always talk about failure in tech as if it’s a badge of honor, but it’s terrible,” says Ken Norton, seasoned product leader, partner at GV, and avid cyclist. “It’s not like I celebrate when I crash my bike.

“But failure is a natural thing we do when building products, just as the threat of crashing your bike is a part of getting on the bike. Every time we fail, we have new data. Now, I know not to try that wet corner at 35 miles per hour without leaning into it,” he says with a smile.  

On a bike or in the boardroom, Ken Norton has climbed his fair share of metaphorical and professional switchbacks. Instrumental in developing GV’s portfolio, which includes  Uber, Slack, Nest, and One Medical Group, he mentors founders on all things product-related. He also serves as the acting PM for the fund’s engineering team and curates a weekly newsletter, “Bringing the Donuts”, which is read by thousands of subscribers in Silicon Valley and beyond.  

From leading product teams for Mobile Maps, Google Calendar, and Google Docs, to joining GV’s operations team, Ken didn’t just pump through tough sprints or push through resistance on his Trek. Being a PM requires endurance, honesty, and sheer determination.

While technical know-how is critical for a career in product, this former software engineer learned that one of the more powerful skill sets is developing a discipline of saying no. This isn’t about shutting down ideas or being bossy. The discipline of no is about sticking to what’s important and clearing away obstacles so the real priorities gain momentum. Looking back on what has made him effective over the years, Ken shares the times where he had to sweat through uncomfortable yet necessary conversations and set boundaries. Committing to a discipline of no has paradoxically fueled Ken’s career trajectory, and it’s his go-to drill when managing teams, and even, confronting decision-makers.

Just like no one wants to recount the worst bike crash they’ve ever had, no one wants to reveal their weaknesses at work. But, when asked, Ken Norton says confronting his personal fumbles redirected his entire approach.

“I’m naturally a very collaborative, eager-to-please person. I’m an introvert. I’m conflict-averse,” Ken says, “So the thing that I struggled the most with, particularly when I was moving from engineering to product, was being able to say no. Being unable to say no hurt me a lot early in my career, and it was actually a skill that took me a long time to develop.”

Being an introvert doesn’t bar you from a career in product. However, after evaluating how his personality influenced his work style, Ken decided to adjust a few of his communication habits. The worst thing about being unable to say no, Ken explains, is that it creates ambiguity – for the team, and for yourself.

If you’re a product manager or leading a product team, you can probably relate to the many times when a sales manager or support engineer requests a change or a new feature based on customer feedback. Instead of clearly stating, “You know, that new feature isn’t a priority for us, in terms of the next six months,” you might say, “Okay, we’ll look into it.”

“We’ll look into it” is like biking straight into traffic. You can bet there’s going to be a collision down the road. Six months later, that same sales manager will check in on that feature you were “looking into” and learn it was an empty promise. This is tough to navigate because the customer feedback could be valid, but it’s just may not be  a high enough priority.  

“In general, it’s best to just say no, because if it’s not a set priority, ambiguity creates a lot of missed expectations and frustration on the team,” Ken continues. “Ambiguity is the worst thing in product management because when you’re not clear on what you’re saying no to, it creates a lot of decision debt, which affects a team’s focus and motivation.”

“What I like to remember is that saying ‘no’ to one thing is saying yes to something else. There are only a few things a team can really focus on. When you categorize something as non-urgent or non-important, that’s not saying things won’t change in the future. It just means there are other priorities that take precedence.”

Ultimately, what a product manager has to constantly fight is ambiguity. There’s no room for being unclear. Goals have to be set and measurable. The timeline is finalized with milestones and benchmarks. Everyone on the team is honed in on what has to be done to hit their marks. But just because things are clear and decided doesn’t mean it’s going to be easy.

In the world of product, being (and staying) uncomfortable, Ken Norton said in a recent keynote, is something to get used to. The liaisons between the executive team, engineering and design, product managers are often at the center of conflict. Product management quickly turns to diplomacy when people disagree on what’s important to prioritize. And in these cases, it’s important not to frame a conversation about priorities as a “people problem.” When fighting ambiguity it should never get personal.

However, this is particularly tricky when the ambiguity is due to “the boss” waffling. While it may get intimidating, a product manager has to facilitate a conversation with important stakeholders so there’s a clear resolution on how to act. This isn’t just necessary for the team’s workload and focus but also for the integrity of the product.

In tech, the inability to say no is a symptom of a larger problem of ambiguity. It’s why it’s so important that leaders make definitive choices in product roadmaps and paint a vision of the company. If there’s not a clear pin dropped in the proverbial Google Map, how can any one move in the right direction?

“I’ve definitely had to sunset products before, but when I look back on why we ended a product, it was largely due to the fact that the leaders weren’t fully committed to the idea from the beginning,” Ken says. “I remember working for a difficult person who ran an org and, despite his apprehension around the concept, still thought it was worth having me and a few other people thinking about it.”

For Ken, this was frustrating.

“I spent more of my energy trying to convince the leader of the org that this product was something we should actually invest in, rather than putting that energy towards managing the team to build it,” he continued.  

Ken now knows how he should have been communicating. “What we needed from leadership was an affirmative, let’s go all in on this. Let’s put people behind it, let’s put energy behind it, let’s put the rest of the company’s focus on it. But we couldn’t get that until we convinced them,” Ken remembers.

Hindsight is the greatest teacher, and from this experience Ken realized that he should have “forced a decision.” Though it sounds confrontational to do so, pushing leaders to make a decision doesn’t have to be without tact.

Reflecting, Ken wishes he could have said to this org leader: “We can’t be in this half-alive, half-dead state. If we don’t get a yes, we’re going to have to stop because we’re not going to accomplish what we want to accomplish without your full support and investment.”

“This definitely goes back to my belief that making no decision is worse than saying ‘no.’” Forcing a decision, Ken explains, is part of the PM job description. And unique to other roles in an organization, product managers have a powerful currency when it comes to bringing people together with the sole purpose to resolve issues.  

“If I’ve got three different people that disagree, then it’s my job to get them all together and come to an agreement on what to do next,” says Ken. “If people want to argue, that’s fine, and the decision may not go the way I want it to go, but at least we reached a point of decision.”

It’s in these moments where Ken feels like a product manager is also a mediator. The goal is to reach a decision. No decision is not an option. At Google, aligning complex sets of priorities is par for the course, but this is mostly due to the fact that products are very integrated. As he puts it, “Things can’t just be shipped in a vacuum.”

“A product may be linked with Android Maps and the Homepage, so as the product manager you would have to bring all the necessary teams together to decide what you need from each of them,” he explains. Do I want this team to commit to letting me ship my feature in their code, or do I want them to commit to giving me the support I need?

When there are many factors and opinions at play, it may seem impossible to come to a resolution. In these cases, deferring to those above you is best.

“While at many companies escalating to a manager is seen as passive aggressive – because you’re either trying to box someone else out, or it’s some kind of ‘failure’ –  sometimes it’s the best way to come to a conclusion on what needs to be done,” Ken says.

“Besides, that’s the whole reason managers exist – they help resolve conflict. But what’s most important to remember when you do bring a manager into a conflict is that you have to communicate the consequences of not making a decision.”

We’ve got 15 people waiting. We’ve got 10 people who have built this thing that now can’t be shipped. We’ve got 20 million users who can’t do X and Y. What are the consequences of it? In these cases, clearly stating the trade-offs or illustrating the repercussions of inaction is the most effective way to inspire people to make a decision.

PMs need to hone the fine art of briefing your superiors – being able to objectively interpret both sides of the argument, spell out the consequences, facilitate a healthy discussion and get a yes-or-no decision.

While advocating for diverse opinions sounds like a key ability in product, there will be a number of times where you have to be the voice of the people who might disagree with you and others. In fact, those you speak for might not even be in the room.

“If you’re meeting with the executives, marketing, and sales team, and you’re talking about a new product direction, you have to speak on behalf of the engineer,” Ken states. “And, if you’re with the entire team, and you work at a startup, and your founder or CEO is not in the room, you need to be able to channel the CEO in the room. Often times, at Google we’d think, ‘If Larry Page was in the room, he would remind us …’”

Ken calls this meeting technique “filling the empty chair.” But this isn’t just being someone’s proxy and voting for consensus. In fact, when you’re filling the emptying chair it’s probably even more important to share what ‘your person’ would say no to more so than what they’d agree upon. Because when a room is filled with yes’s, oftentimes the conversation desperately needs someone with the foresight to spot the potential potholes. For example, when representing an engineer, a PM needs to remember the limitations of the code. 

Sure, when you’re the only person in the room giving a version of “no”, it might seem like you’re just pumping the brakes on a meeting’s momentum. But what you’re actually doing is staying true to preset priorities and accurately expressing stakeholder points of view. From the onset, it’s important to make it clear why you’re contesting an idea so it doesn’t seem like you’re disagreeing for argument’s sake. And when discussing technical matters, it’s even more important to have incredibly clear communication skills.

While engineers may implement code, product managers still have to understand the architecture so they can express, with confidence and specificity, whether a new feature is possible, given the current framework.

There’s no room for ambiguity during technical conversations. This may actually be why some of the most logical and clear communicators in product are also those who hail from technical backgrounds.

Before the idea of product and venture capital was even in his sightline, Ken was a software engineer, a CTO, and a founder of a cloud integration platform company.

“I recognized pretty early on that I’m an okay programmer. I’m not a great programmer,” says Ken. “I tended to be the engineer that everybody wanted to ask questions when it came to technical details, or when they needed an engineer on a sales call or in marketing meeting.”

At the juncture of implementing software and architecting it, Ken switched gears. But before he officially transitioned into the “product track” – by starting his own company – he learned that the most valuable prerequisites for a career in product can’t be practiced in a vacuum. They hinge on communicating and working with others.

“So much of PMing is code-switching amongst different types of professionals or large groups,” Ken remarks. Being able to steer through personal and group dynamics is not just an important skill for PMs, but any technical leader, whether you’re young or seasoned in your career. Who you communicate to and how you convince or inspire someone, or an entire team, will inevitably affect the entire process and the end result.

While Ken’s discipline of no sounds one-dimensional, he would also be the first to admit that saying no doesn’t rule out being flexible or a good listener. In fact, the interdisciplinary nature of product management requires flexibility. It’s one of the keystones to his rubric. When shuttling between roles of mediator, liaison, and sometimes even instigator, having that adaptive nature, to alter your focus or tone depending on the audience, is foundational to effective communication.

Photographs by Stephen Bowler, Graham Campbell, and Jeremy Segrott made available under an Attribution 2.0 Generic license.