The Switch: Lessons learned from a Beta Tester turned Product Analyst
“Hey Anisha, I just received an email from Connie on Software Engineering, and she will be putting some time on your calendar for next week,” my Manager, Natalie, told me one snowy morning in January 2016.
“Sure,” I said, without giving it much thought. “What is this about?”
“Something about a new delivery system? They need volunteers. I’m sure she’ll give you all the details next week.”
That was the day I became an AlphaTester for our new internal research and sales app. And little did I know, that was the day I started to develop an interest in technology and building software. I was extremely excited to get a sneak peek behind the scenes of this mysterious software of which my team at the time, Client Service Team (CST), had only heard rumors.
Probably a good time for an introduction, huh?
I’m Anisha and I’m currently a Product Analyst on the Software Engineering (SE) team at AlphaSights NY. I grew up in Bombay, India, went to Tufts University for my Bachelor’s degree, and initially joined AlphaSights’ Client Service Team in 2014 before switching to my current role in 2016. AlphaSights is an information services firm that provides the world’s top professionals the knowledge they need to make crucial business decisions. Our CST teams partner with the top consultancies, investment firms, MNCs and non-profits under extremely tight timelines and competitive environments.
The transition from CST to SE was a unique one given my previous background. Most of my peers went on to become Account Managers or back to school for a Master’s degree. I was fortunate that this move was intra-company, with both my previous and new teams rooting for my success. Our SE team also has a “learning” budget, and I made it to the Mind the Product conference in San Francisco two months into this new role.
Given that I’m coming up on six months, I wanted to share some of my reflections, specifically on how I had to adjust my thinking and working style when I moved from Sales to Product.
1. Long lists of to-dos will lead to disappointment
Coming from the fast-paced CST environment, I would plan my day similarly — making lists of tasks I wanted to knock out before heading to my 7 pm spin class.
I was going into morning stand-up meeting, promising to do multiple SQL data pulls, three customer interviews and two hours of white-boarding. But for the first month, this habit made me feel inadequate and unaccomplished. I quickly learned, that focusing on only one or two tasks a day (and sometimes an entire iteration!) not only led to more efficiency, but made me a better product manager to my team. It was more important for me to own 100% of one problem area, than 10% of ten different ones.
2. If you don’t run into problems with your first Pull Request, you are not learning
I had the fortunate (though I probably didn’t feel that way at the time) experience of having to revert my first PR. I wanted to track some web analytics on a feature, and did so by adding fields into our tracking function. Not only did the change not track what I intended it to, it also blocked the tracking of other fields. I had to immediately pair with our in-house expert data engineer to revert the PR and do a post-mortem. While this was disheartening, it was important for me to remember that i) it was good that we caught the mistake early ii) it forced me to think about every task not to just “get it done” but to carefully evaluate all possible scenarios and edge cases before going ahead with any changes to production.
3. Meeting time = decision time
Before officially joining the SE team, I received several invites for meetings for after I transitioned over. I distinctly remember how overwhelmed I felt. On CST, I believed that having more meetings inversely impacted the speed and quality of service to my clients. I would work extra hours to make up for “lost time.”
My opinion of meetings has taken a 180 degree turn. I’m not advocating for more meetings, but I strongly believe that with the right attendees and agendas, meetings can be the time to make important decisions and remove any roadblocks.
4. Your teammates are your best teachers
No number of blogs, reading, or classes has given me the same benefit than pairing with the people sitting around me — whether it has been in iteration planning sessions with lead engineers, or during hackathon days learning Rails with a new joiner on our team. We don’t build anything by ourselves, and not every person on an engineering team is the same. There is immense opportunity to learn and grow, if you are open-minded and willing..
If you’re interested in joining a team like mine, we’re hiring.
