These series of posts are based on my recent experience with starting a startup, and how I went about it with my partner to get us both on the same page for us to develop a strategy we both believe in and can execute on.
I bet you know what you want to do.
I bet you know how you want to do it.
But do you know why you want to do it?
Why are you willing to put your reputation on the line? Why are you willing to put your career on the line? Why are you willing to alienate yourself from your friends and family during tough times by working nights and weekends with the hope this thing gets off the ground and makes a dent in the universe?
There’s only one answer to these questions: the why.
As a Product Manager, I often describe what I do falls into 4 or so buckets:
- High-level: Where should the product be going?
- Low-Level: What is the next thing we should build that will help us get closer to our goals/target?
- Discovery: What is the exact problem are we trying to solve and what is the outcome we want to achieve?
- Delivery: How do we build this solution we “discovered” during the Discovery phase?
- Analysis: Did what we design and build during the Execution Phase solve our users problems and bring us closer to our goals? Why or why not?
- Support: How can I help the rest of the organization? This includes working with Customer Success to help them understand the inner workings of new features/processes, and working with Marketing to educate our customers on these new features/processes.
I strongly believe that a Product Manager who cannot execute is not a Product Manager. You may have the great ideas/strategy but if you cannot work with your product team to validate the idea, build it and ship it, then what’s the point of having all these great ideas?!
I also believe that we’ve greatly improved our Delivery Process over the last 10-20 years. We now use some version of Agile with Scrum, Kanban, Sprint Planning meetings, etc. to break things up for the Engineering team, and most organizations deliver on at least a weekly basis or are hopefully moving to Continuous Integration and/or Continuous Integration.
The Analysis aspect is also easier than before. We can use services like MixPanel, Kissmetrics, and Amplitude to see what actions our users are doing, then create dashboards to understand trends using Periscope and Chartio.
What I’ve felt we’ve not yet effectively conquered as a disciple/profession are the Strategy and Discovery aspects, which are the most critical for any tech team since they help you avoid building crap.
Strategy is something I’ve recently started diving deep into so at this time I do not have a strong viewpoint to share, but I can share with you on how my Discovery process has changed over the last 3.5 years of being a Product Manager.
Couple things to note before we continue:
- I am not taking credit for coming up with any of these processes. Some were in place when I arrived while some I helped shape.
- These version numbers are arbitrary in a way; I grouped certain things together depending on when I started at a new company or when we found a process that worked for some timeframe.
Not sure what Discovery is or what some more detail, take a quick look at this post before continuing.
Let’s jump in:
Discovery is a process we use as product people to better understand the problems we are trying to solve for the customers we are trying to solve the problems for. It also helps us ensure that it is the right problem for us to concentrate on since there are always a million other problems we need to be solving at any given moment. My understanding of Discovery is mostly influenced by Marty Cagan, who walked me through the concept during of his “How To Create Products Customers Love” workshops. (highly recommended!).
In Discovery, we want to do two things:
- Understand what the problem is and validate it (Problem Discovery)
- Understand what the right solution is and validate it (Solution Discovery)
Let’s look at what these two entail:
I was recently talking to Europe-based FinTech startup who were looking to hire their first Product Manager (PM), and they wanted this potential PM to be based in New York (NYC) rather than in Europe with the rest of the company. Their rationale was logical: the majority of their current and potential clients are in the US, particularly in NYC since they operate in the Financial realm, and they wanted that PM to be as close to their customers as possible.
This situation got me thinking that they have three potential options:
- Option A: Hire an NYC-based PM who can readily and easily travel to customer sites (current plan)
- Option B: Move the product team and/or the company to the US
- Option C: Hire a Europe-based PM to be collated with the company in Europe
Ideally, the entire company should relocate to where the majority of its customers are, especially since the company is quite small at its stage.
Relocating the company would provide two enormous benefits:
- The team is together
- You are near your customers
But let’s say, for some reason, relocating the company (Option B) is out of the question. Should the startup continue as plan and hire an NYC-based PM so that the PM is close to their customers (Option A), or should they hire a Europe-based PM to that the PM is close to the product team?
Based on my experience, I would strongly recommend hiring a Europe-based PM and here’s why:
In my last post, I explained how Intercom is such a wonderful tool and makes my life as a product manager easier by making the following tasks straightforward:
- Intercom allows me to find the right users to do the three types of user research I need to discover, design and build useful features for my customers
- Intercom allows me to set up auto-message tips to send to my users based on whether they have done a particular action or not.
But, as I use Intercom more and more, I’m starting to realize there are certain limitations Intercom has (either by design or not), and I need to get around them somehow…
Here’s how Intercom is breaking for me:
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.