How to Be a Scientist, Not an Expert: Presented by ISPOSSIBLE WOMEN WHO ROCK and Pivotal Labs by Katherine Pitney May 1, 2015

On Thursday, April 30th, ISPOSSIBLE WOMEN WHO ROCK came together with Pivotal Labs to host an amazingly educational and energetic event, How to Be a Scientist, Not an Expert. The event was led by Tiffany Roesler, the president of ISPOSSIBLE IN TECH, Linda Joy, a product designer at Pivotal Labs, and Lauren Gilchrist, a product manager at Pivotal Labs.


The event began with a brief introduction from Tiffany, who provided the definition of ISPOSSIBLE WOMEN WHO ROCK. Tiffany explained that ISPOSSIBLE WOMEN WHO ROCK is a group designed to help people break through their impossible by empowering women to come together to create, lead, instruct, bond, take risks, and all-around rock. And in doing so, Tiffany recognizes that a community of strong female leaders in tech can be built, which, in turn, will fuel their capabilities for creation and encourage younger members of the female tech community to take the leap and become leaders themselves. ISPOSSIBLE WOMEN WHO ROCK is a group that is open to all, Tiffany said, membership only has two simple requirements: start by using the word "we" and then say that you rock (because, let's be honest, you do.) Linda took the podium next and delved into the difference between being an expert and being a scientist, and why the latter is the attitude you need to adopt to succeed within the tech industry. Linda stated that the crux of being a scientist, rather than an expert, is a willingness to let go of the idea of getting everything right the first time.


An expert believes that she knows everything and is capable of creating the prefect product on her first try. And as Linda explained, it is incredibly difficult to avoid falling into the trap of perceiving yourself, or being perceived as, an expert when all we want to do professionally is portray ourselves as all-knowing rock stars with limitless capabilities. But when we adopt the attitude of the expert, that's when we run the risk of being caught not knowing everything. Instead, we need to adopt the attitude of the scientist, who recognizes the necessity of doing research into her users' actionable needs and desires. The scientist isn't afraid to ask questions-even seemingly obvious ones-because that's when her work is grounded in reality.


Linda then went on to explain a few tips and tricks she uses to get out of her own head and her own way to be the scientist she needs to be. First and foremost, she stated, a scientist must test rigorously and often, always ask herself if she can test something in a simpler way, and take the time to test one feature at a time so that she can have a manageable amount of actionable feedback to work from. Next, Linda went on to explain the truth behind social listening, in that when we listen, we are really only listening for our own chance to speak. But a good scientist not only really listens to her users' feedback, but also wants to understand her users' behavior so that she can better comprehend and predict her users' needs. Without being attuned to your users' behavior, you have nothing but verbal feedback to work from, and more often than not, users are going to give the verbal feedback they think you want to hear.
But scientists aren't afraid of being wrong or testing and re-testing, Linda said, it helps them avoid the huge problem of releasing a poor product. Test as soon as possible, and test by talking to your users. Always question yourself; listen to your inner scientist and get out of your own way, Linda closed.


Lauren then took the stage to delve deeper into the process of user-testing and what a scientist must do when she reenters the building to tackle the seemingly endless list of problems she just discovered her product has.
You can't answer any questions sitting at a conference table, Lauren said, you need to speak to your users and capture their feedback effectively. At Pivotal, she said, we have weekly testing sessions with users to ensure we are communicating with our users often enough to maintain a manageable amount of feedback to work off of. Lauren also strongly advised against asking leading questions; instead ask your users about their past behaviors to learn about their needs and desires. Further, when you speak with your users, capture their feedback verbatim and always be sure to note the frequency with which each problem occurs.


Of course, once you speak to your users, you learn two (incredibly overwhelming) truths: your users have a lot of problems, and some of those problems are very difficult to solve. And all of a sudden your head is spinning, Lauren said, because it is your job to solve all those problems and now you feel like you're failing. But you're a scientist, not an expert, and you need to recognize that you aren't failing, you're simply in the process of iteratively building the best product you can.


Once you have adequately captured your users' feedback, Lauren went on, you then need to synthesize it all into an organized list of problems, with the first priority being the problem most likely to kill your company. Therefore, all problems must be sorted by frequency vs. impact. Of course it's tempting to try to solve the simple yet frequent problems first, or the "seductive distractions", as Lauren coined them. But if you ignore the elephant in the room and attempt to solve these seductive distractions, you will run out of funding and kill your project. Instead, as a scientist, you must take the most devastating and frequently occurring problem and ask yourself, "What is the easiest way for me to fix this?" And if that solution doesn't work, move on to the second easiest way to solve it, and so forth until the problem is adequately solved.


That's the process, Lauren said, implement, validate, and repeat. As a scientist, you need to be comfortable putting on your big girl pants and not solving the problem on your very first try. Now you just need the courage to go out there, fail, and start learning, Lauren concluded.

Best,

Tiffany