Blog Viewer

Member Q&A: Google's Parag Vaish on Smart Team Decision-Making

By Emily Cowan posted 02-07-2019 12:00 AM

At our Customer Response Summit in New Orleans we heard Parag Vaish, Founder-in-Residence at Google's Area 120, explain how his Smart Selection Process helps the most valuable CX ideas and strategies float to the top. In this follow-up Q&A, Parag shared how he navigates office politics, when it’s OK to greenlight a project with little data, and why a difference of opinion among team members can lead to laughs in the conference room.

Execs In The Know: In your presentation you referenced the OGSM Model (Objective, Goals, Strategies, Measures). In your experience, what are the areas where people were most likely to stumble and what recommendations would you provide to ensure success within the framework?

Parag Vaish: If the contributors to the process come in with a political agenda, that can be a problem. In my book Team Decision Matrix I reference a character at StubHub who walked into a nine-person prioritization meeting and said, “If I am one of nine people participating in this process, then my project will never win because I don’t have enough votes.” This was a politically motivated mindset, which will derail the end result. Also, if anyone has the ability to see anyone else’s assessment/valuation of each project prior to concluding their own assessment/valuation, then you lose the integrity of the blind assessment. Someone can manipulate their opinion to resemble the scores of “the boss” in the room to make themselves appear like-minded.I don’t recommend using the OGSM framework to answer questions like, “Should we acquire company X?” or “Of this list of bugs, which are the most valuable?” I have found that these types of questions are too big or two small for the process, although I’m not saying it won’t work or it’s not worth trying.

EITK: In your presentation you walked us through how you took multiple ideas and placed them into a product prioritization. Part of that was limiting the ideas being submitted to a 140-character description to determine size of effort required. Did the descriptions that were provided automatically feed into the scorer spreadsheet or did you have to individually rate each specific one for level of effort?

Parag: Good question! The 140-character description was to encourage brevity and clarity. Then, at the start of the assessment/valuation, I had the product manager read the project description. Being that it was 140 characters, this would usually take less than 30 seconds. Then, the group would provide their assessment/valuation within the next 30 seconds, bringing the total time invested to 60 seconds or less. This gave me the ability to say it was a “light weight prioritization model” when I was first creating it. 

Specific to your question, the description was not visible to the contributors on their spreadsheet, but that was just a function of the spreadsheet, not because I wanted to withhold it. Equally as important, it is critical that all the contributors hear the same articulation of the projects and provide their assessments/valuation at the same time. This ensures that there aren’t different interpretations of the projects.

EITK: At what point in the process do you reveal the results of the initial blind-assessment scoring to your team members, and have you experienced any "political" fallout when team members' opinions diverge significantly?

Parag: The best practice is to collect the data in a blind fashion, reveal the unfiltered data to the group shortly thereafter (depending on the size, it might be a day or two later), and then discuss the differences. At that point, it is important to give people the opportunity to amend their assessment/valuation. Because the discussion would reveal misunderstandings, new data for or against a project, etc. Then, you reconvene with a revised assessment with the person leading the process recommending the projects to proceed forward with. Usually, this would be a few more than what can be accomplished so that you can discuss and replace items as you see fit within the group. 

Regarding “political” fallout, I’ve actually seen it go the other way, where it is quite humorous to see the different opinions. For example, I saw a strong correlation between low scores and high tenure at the company. A person who has been at the company tends to be pessimistic on the value of any one project. This usually results in quite a bit of laughter. You might also see this with engineers versus product managers. Depending on your group, this can be quite humorous.

EITK: How do you decide who is part of the team? It seems like that group has to be large enough that different points of view are incorporated, but can become too large very quickly. 

Parag: The team composition is critical to the success of this model,so I’m glad you asked! I would say the optimal number of people is seven, plus or minus two. As far as the job disciplines, you want a cross section that is appropriate. If you are using it for software development on a mobile app, for example, then I would recommend the product manager, designer, QA, and engineering representatives. Practically, you might need two designers, or three engineers, so that folks who are equal participants don’t feel left out, so there is judgement here. I have done this with 10+ people, but never more than about 15.

EITK: In your past few roles you've obviously had direct access to and influence at the executive level to be able to influence this adoption approach and the ideas that were identified. For those of us who may not have that access or influence yet, what advice can you share to get that "seat at the table"?

Parag: I would recommend doing the scoring/prioritization process that I described on stage and in the book with a controlled group of people, and then showing the results to a senior team member. This exposes the end result and its associated value, rather than trying to convince someone of a hypothetical process and benefit. (You can find the spreadsheet for Scorer Inputs on my OGSM model here.)

When I first did the Team Decision Matrix at StubHub, I started with a small team and then showed it to the CTO. She immediately said, “We should be doing this with the leadership team as well!” What I learned, as it relates to your question, is that a good and strong senior leader will recognize places where this model can be more appropriately used and they begin to champion it. But, you may need to show them the end value first, rather than, “Hey, I learned this at a conference and think we should try it.” 

The other benefit to you, is that you become regarded differently by that senior person. They will see you as creative, dedicated, and invested in the company because of your interest in helping to solve problems. That alone may break you into the executive level you are seeking.

EITK: Is there ever a time when is is acceptable to greenlight a project because you know it is the right thing to do for customers?

Parag: There certainly are acceptable reasons to green-light projects without data. I know your question was when it is “right for customers” but there are other reasons, too. While I was at StubHub, I greenlit the StubHub Alexa Skill at a time when the Alexa product had very little traction and resources were very precious at StubHub. It was a hard decision which was met with many critics, but I needed to do it for a few reasons (in no particular order): 

  • Our engineering team needed to feel innovative. They were getting relegated to incremental improvements for short term revenue sake. This doesn’t sustain the highest quality engineers in the long run.
  • We wanted to have StubHub perceived differently in the marketplace. Instead of being the last place where you turn for tickets, we wanted to be a discovery mechanism, and the Alexa skill would allow fans to hear the answer to “what’s happening in Portland tonight?”
  • This was a perfect intern project! I used three engineering interns for this project and Amazon offered two full-time engineers to help. And, it was a relatively tiny investment.
  • I had to put my stake in the ground. Politically at StubHub, it was important for me to show the entire technology team (~400 people) that their leader was willing and able to make tough decisions and not take orders from sales teams. 

So, yes, there are many reasons to green-light projects in addition to the intuition that it is “right for customers.”

Execs In The Know is a community of high-caliber customer experience executives who are on a mission to build brand equity through extraordinary customer experiences. Our online community is a private professional networking platform where CX Leaders can work together to help solve current challenges, build new strategies, and position for the future. Join us!


Are You a CX Leader?

KIA Community is Execs In The Know's private online discussion forum for CX Leaders. All senior CX executives at consumer brands are welcome (no business partners, please)! Click here to request to join.