Guest Post by: Valia Lekka (Mentee, Session 6, The Product Mentor) [Paired with Mentor, Felix Sargent]
A little less than two years ago, I joined the first in Greece to receive large venture capital funding, to have great offices, perks and a wonderful working environment.
I was hired to become the product manager for the company’s mobile products. I had never done anything similar before, the team was completely new, half of the people on the team were younger than 25 and no other company in our industry had native mobile apps with the level of sophistication which we wanted to reach.
‘Being in survival mode’ for the following 6 months would be an understatement. Since our main objective was to include a subset of the main product’s functionality, most of our roadmap for the next 6 months was clear. However, it was a lot of work. Not everything that works on desktop works on mobile.
We left automation testing behind. That team was trying to cover two years’ of main product’s functionality in six months. The mobile team was not getting full coverage on an automation suite any time soon.
The only way to know there weren’t any bugs was for me to test manually. It was the only part of my job that I absolutely did not want to do. Testing took up almost 70% of my time.I was dreading every release thinking whether I went through all possible flows. Stories in our user story tracker were waiting for my acceptance for weeks before I was able to get to them and have them released. My boss thought that we were too slow, the developers wanted to close open branches and I was trying to be thorough enough so I could get a good night’s sleep.
Nine months had passed after I was hired and we had delivered two native apps and one mobile web app. I was sick of everything. Manually testing every single feature and then doing some manual regression testing on top just didn’t scale. I started talking about our testing problems with the more senior people in the company but we weren’t getting anywhere. This topic was polarising and people had very different opinions about it.
In January 2016 I joined the Product Mentor program and very reluctantly I started talking about this issue with my Mentor, Felix Sargent. My expression of the problem was 20% the description of the problem and 80% self flagellation and doubt. ‘Is that a real problem or am I making it up? I’m probably not very good at my job, right? Other people would have solved this issue in a day, right?’.
My mentor was patient enough to ask me the correct questions so that we could identify the problem in a sober manner. It’s very easy to doubt everything you’re doing especially if one is as green as I was. Through the conversations we had, I realised that if something makes you feel tired and you keep asking yourself : ’Is this really the best way to do this?’ then something is up.
It was a revelation. We all want to do a good job and get good results. But in order to achieve our goals we have to take a step back and identify the problem instead of blaming ourselves.
The issue was now clearer. We trusted blindly that the developers would produce quality code and that I would be able to test it manually. But I didn’t have infinite time, and my work testing was taking me away from being able to be an effective product manager. We needed to figure out a way to do automate the process.
I was very lucky to have a mentor who had an opinion on this. He shared articles with me which explained how other companies had dealt with this issue, without pouring more resources and more people on the issue. I finally felt like I wasn’t the only one suffering from this issue. I finally realized it’s a hard problem and it wasn’t just a matter of working harder. I needed to change the way that the team operated.
So I started talking. I talked to my boss, I talked to my team, I talked to the QA manager. When I explained the problem and proposed a solution, people listened.
The proposal was: Have the developers write their own end to end tests, put the QA people in a position where they build the infrastructure for that to be possible and then start measuring. Measure the time spent on manual testing, the number of bugs that come out in production, the number of bugs the developers find while writing their tests. Measure everything. See where we can improve. Make the team responsible for the quality of their work.
The first sprint we tried it was a disaster. It took us weeks to write the tests and when we tried to put them all together nothing worked.
Then a few weeks in, disaster struck. Our QA engineer quit. He was not happy.e felt he was left with all of the “grunt work” of creating fixtures, reruns and putting all of the tests together.
We lost the QA Engineer, as we couldn’t to fix all of the issues with the process. But here is the beauty of what we did: teams lose people and for different reasons. 3 months ago losing the QA Engineer would have been a disaster, now it’s a lesson learnt. One that we are able to take on as a team and solve as a team.
We are now on our fourth sprint. It is still not easy, but the gains make up for it. I have cut down the time manually testing the flows to almost half and the developers correct a lot of the bugs while writing the tests themselves. I finally have enough time to be a Product Manager.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Check out the Mentors & Enjoy!
The Product Guy