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!