Hiring For Your Product Team

Problem

"While I was working for iQMetrix in Vancouver as a Senior Business Analyst, I was pulled in with two other guys to build up a new group to work on a big enterprise project for one of our clients. It was an extension of our company's core product and I was tasked with expanding the Product Team."

Actions taken

"I was given a massive scope document that was all over the place, so I started out by trying to slice it up into manageable chunks. As we began ramping up our engineering team, I took one of the chunks and dived into one of the first areas we knew we wanted to work on. I then needed to find someone to take over this work on a more detailed level. We went through a lot of interviews with various candidates for business analyst and product owner roles. However, a lot of people struggled with breaking down a big piece of work into manageable sized pieces. Because we were given such a large project with a fairly vague scope, we needed someone who was able to take something that was relatively abstract and break the scope down into smaller and smaller chunks until the developers were able to pick up tasks. While going through the hiring process, we had a recruiter do pre-screen interviews for us and we would then get prospective candidates resumes. Because I was working directly with the developers, I tended to look for people who had some experience with coding, so we could talk the same language as them. As we went through the interview process, I found that a really good way of gauging how candidates broke down ideas was to pose a problem for them to solve on the whiteboard. At first, the problem was pretty complex, as I asked them what would they need if they were to build Amazon again. This threw off a few people, so I realized I needed to simplify the problem. We were looking for intermediate-senior business analysts or product owners, so I revised it to a login page, and told them "If you're building a login page, what do you need to tell your developers what they should build?" Some candidates jumped straight into writing user stories, which is not necessarily bad, but if they couldn't think of these as part of a larger picture, e.g. consider the need for a forgotten password or registration flow, it indicated to me that they would struggle with taking a larger abstract chunk of scope, and work through it one layer at a time. This process turned out really well, and we hired all five of the people who were able to do this."

Key Quote:

"It's important to find a way to challenge your candidates to determine whether they have the skills you're looking for. The whiteboard test was particularly effective for me."

Lessons learned

"One of the reasons for this is when you work directly with developers they will often ask questions out of the blue. As a business analyst, or product owner, you need to either be able to answer them or realize you can't and gather more data. Finding a way for candidates to show that they could think on their feet was really helpful."