I was very excited when I first heard about Intercom, and a bit surprised why it took so long for such a product to come out. It just made sense!
Although there were existing tools out there that allowed you to talk to your users, such as Qualaroo and Olark, Intercom did something different, it allowed you to have conversations AND see who was using what in your app AND connect with them. It mixed customer interaction + app metrics. This combination of capabilities is great since you didn’t have to build a similar tool yourself or use multiple tools to achieve the same outcomes.
It took me almost a year after hearing about Intercom before I could finally start using, and once I started using it, I was addicted to it. Here’s how it’s made my life easier:
Previously, I shared some of the questions I like to ask when interviewing with an organization for a Product Manager position. One thing I quickly realized while interviewing back in the day was that interviewing at an established company or former startup is quite different than interviewing at a startup, and that’s because the startups deal with a lot of risk around viability.
You might say that all organizations, whether they are startups or not, deal with risk, and risk comes with working anywhere. But, as a Canadian working in the US on a work, I knew that if I wanted to work for a startup, I needed to understand for myself whether the startup in question had the potential to succeed. I took this aspect seriously because if I joined a startup that tanked, I would have to leave the US promptly and then try looking for a job in the US from Canada…and that’s something I wouldn’t be very excited about doing. In addition, I wanted to find an organization that I could be with for the next couple of years.
So how could I understand whether a startup had potential to succeed (or at least survive for the next 12 months)?
Well, by having an honest and open conversation with the founders of the startup and asking these questions:
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.