Interviewing for a Product Manager role is not an easy task, especially since there are just so many factors that can make a company either the best place to work at or the worst place to work at. A year ago, well pretty much exactly a year ago, I wrote about the 6 Fits every Product Manager should consider before accepting a job, to help understand if this job is the job for you. This article became my second most popular article, behind the slightly controversial Waterfall vs Agile vs Lean post.
We’ve all heard how important it is to ask questions during interviews, not only for you to figure out if this role is for you, but also because it shows your prospective manager/company that you are thoughtful and care about what you do with your life. But coming up with good questions in not easy, especially if you are new to Product Management and are not sure what to ask, or you’ve been out of the interview game and are a little rusty.
The side benefit to asking good questions makes you look like a candidate who wants to work there
Over the last three years, and after interviewing with ~50 organizations, I’ve developed a list of questions for me to ask, in case they were not answered during the interview, to help ensure that I understand the role and company as much as possible, and most importantly, whether a specific role and company are the best for me.
The tech industry is changing so rapidly. Every day, hundreds of articles are being written about trends, new technologies, new patterns, new processes and new learnings.
You could go crazy trying to keep up with everything out there!
Although I haven’t found a secret way of easily digesting the information into my brain, I have figured out how to effectively reduce the amount of time I spend looking for things to learn about.
How do I do it?
Between my 4 co-ops and my two Product Manager positions, I’ve used a number of tools for product development and bug fixing including Bugzilla, TFS, Rally and Jira, each a respectable tool in its own right with Jira being my favorite.
So it quite surprised me, well maybe shocked me, to find out while interviewing with Hightower that they used what I thought to be such a simple tool for their product development process: Trello.
At Hightower, we release daily. Yeah…daily!
Releasing anything shorter than weekly to me was startling, especially since all my previous tech jobs were mostly a 2-week release cycle, but after a week or two, I finally overcame the shock and started to really enjoy it. Here’s what I learned so far:
If this blog was a river, it seems to be drying up. But please, don’t jump to any conclusions. It’s not as if I just started this blog and kept it going for a couple of months for the sole purpose that it would help me find a new job, and then slowly abandon it….well actually it does seem I did that didn’t it?
Well, let me explain.
It’s been a busy two months! How busy? Well, I feel like I’ve I’ve accomplished more in the last two months than in my previous 2.5ish years in Product Management…so yeah, it’s been nuts. So crazy that I’m writing the draft of this blog post on a plane…that’s a first for me.
But wait, let me back up a bit..
Actually, there are two equally strange pieces of advice I got. One was when I was 15 years old or so, and I joined a DJ pool (think of Birchbox for vinyl, but you get vinyl records 1-6 months before they go on the radio), and the manager of the pool told me “don’t f*** up!”…in front of my dad. I still don’t understand why he said that…
But we’re here to discuss a more relevant piece of advice I got…
I had to do a total of 6 co-ops/internships as part of the University of Waterloo’s Engineering program. One of these co-ops was at NexJ Systems as a Professional Systems Consultant in 2009 where I helped customize financial CRM software for clients.
It seemed like I got chummy (although I didn’t think this was the case) with a manager (whose name we will leave out) and he told me this:
Seriously? Why? Why? Why?!
Usability testing is such a simple activity yet so crucial to getting designs and products right, yet we hardly do it even though we talk about its importance (yes, sometimes I fall into that group).
What scares people off of usability testing is the amount of work involved. Often, we think we must find a small sample of our target audience or users to test on. Although that is the ideal way to conduct usability testing, this can often be hard to do for a number of reasons:
- It’s hard to find a group of people to test with
- It’s hard to get people’s time
- It could be hard to set up (Do I need to build a prototype? Do I have the time and resources to do that?)
- There is not enough time, there are deadlines to meet and the engineering team needs to start building
- There are so many other things you need to move on to
Clearly, there are some obstacles in the way. But nonetheless, usability tests helps us ensure we are building something in the right way. You may have a great idea for a feature and think you have a great design for it, but until you have somebody use it and show you they can use it, it isn’t anything useful or worthy to brag about.
So how can you do usability testing to ensure your great design is truly great even though you don’t have the time or the ability to access your users?
There are two quick ways:
There are many things (aka frameworks, methodologies, good practices, etc.) in Product Development that are like sex in high school: everybody is talking about it, but nobody is doing it. The original “thing” that was classified like sex in high school was A/B testing.
Designing physical spaces and designing software/web/mobile products are not two different. You are solving a problem by creating something of utility, but you want to create an experience around that utility.
Let’s explore some of the questions architects ask and how they can relate to product design.
I had the great honor and pleasure of being a Product/UX mentor/coach for Startup Weekend’s 2015 EdTech competition. I actually participated in 2013 where my team narrowly missed out from winning the top prize!
Here are some of the lessons + insights that I got from this year’s competition that I hope will help future teams: