When you’re running a small startup, you may ask yourself when to hire your first product manager and what you should look for in the candidate. This is a question I get from founders fairly often.
Startup founders in technology companies usually are great at least one of the following things; making stuff and selling stuff. Few individual founders are great at both, but most successful founding teams are excellent at both.
In the early stages of your startup, when you are trying to find product-market fit, you do not need a product manager. As founders (at least one of) you should be the product people at the company – obsess about the product, spend time with customers, drive the product roadmap, etc.
When you have found product/market fit and you are starting to scale, is when you should hire your first product manager. This person can run the day to day product development and allow you (as the founder) to step back and focus on fundraising, product strategy, hiring, and important partnerships. This person should bring you significant leverage.
Many founders think they need a ‘Head of Product’ first – I don’t think that is right. I would not hire a super experienced product person who expects high compensation, owning the entire product vision and strategy or brings in ‘this is how we do things’ from their background.
Instead, I would look for an early/mid stage in their career, who is a strong executor and is high potential and can grow with the company. This person should be passionate about your product, users and you should be excited about mentoring and working closely with them (as founder/CEO).
If this person ends up doing a great job at the execution, they can take on more product strategy from you as you build mutual trust and respect. If they are not able to scale in this role, you can bring in more experienced folks to lead the organization. Replacing a product manager is much easier and less expensive than a head of product.
Over the last few months, I’ve been thinking about how to design a lightweight framework for product development that fits in with different ‘product cultures’ and scales from a few teams of a few people to up to 50 people.
My current ‘best guess’ of this is a modified version of the Now/Next/Later framework that Noah Weiss nicely laid out here. For each product line I’d recommend a separate roadmap of this otherwise it gets pretty unwieldy. You can always roll up specific projects into a higher level company level view, if needed.
Here are some principles that I suggest for your roadmap:
The product roadmap needs to be publicly visible and easily accessible to folks in the whole organization.
It needs to be easy for folks outside the immediate executing team toadd ideas or requests to the ‘New’ section for triaging.
Ideas should be tracked from ideation to completion without duplication of work to update projects by lots of unconnected tools.
The tool you choose is not important, as long as everyone uses it. I’ve enjoyed using Asana in the past (although they don’t integrate super well with other services).
New (Inbox) : This is where all new items start to be prioritized. Items could be anything from large feature ideas, bugs or feature modifications. There should be a clear owner for prioritizing these items, usually the product lead, or on call engineer depending on the type of issue. Large projects should be broken up into milestones and prioritized. Try and keep this section at ‘Inbox Zero’.
Now (In Development) : This is what the team is actively working on right now, in order of priority. These tasks should be assigned to individuals on the team and usually correspond the the current sprint. Tasks in ‘Now’ are granular and well defined and have a clearly scoped deliverable and timeline. If you want more granular ordering or filtering in this list, I suggest tagging tasks by priority (e.g. P1, P2, P3).
Next (On Deck): These are the tasks/features that the team will work on in the next 1-2 development sprints. Tasks in this section should be in rough order of priority and have some definition around them, but may be broken up into more specific tasks when they move into the ‘Now’ bucket.
Later (Icebox): These are items that are unprioritized, but you know you want to get to them at some point. They could be bugs, loosely defined features, or feature modifications which should be tagged for clarity. The order or specificity around these is less important (especially for features) as you will prioritize and add more definition when the time comes.
Not Doing (Pit of Despair) : This bucket of tasks is usually hidden but is a list of ideas that you have explicitly decided that you are not doing. I suggest adding in a comment into the task to articulate the reason why you are not doing it, before moving it to this ‘Not Doing’ bucket.
In addition to the execution priority, it’s also useful to include some way to show the relative importance of tasks, so you can clearly see what tasks in the sprint can not drop. I suggest a Priority (Impact) and Project Size (Effort) tag like I’ve shown below.
This is an example of what a product roadmap could look in Asana:
In an ideal world, the tool is easily used and accessible by everyone in the organization and tightly integrates with other product development tools you use – e.g. Figma, Github, Google docs. Asana does not do a great job here and it’s hard to get information out of Asana if they whole company does not use it (which probably improves their retention, but makes it a worse tool overall).
These principles don’t just apply to user facing product development teams but would be also useful for ‘central teams’ like data/analytics or platform teams who are working cross functionally with folks across the organization. These teams often have ‘requestors’ of their time and expertise. It allows for better visibility into work and timelines, and also provides a structured system to ask for help or request reprioritization of work which hopefully leads to better visibility and trust between ‘central’ teams and ‘product’ teams.
Every company is different and each team may have different norms, but having a set of common principles, common tools and a shared language can improve visibility and reduce the switching costs for managers who oversee lots of projects and individual contributors moving between teams.
I get asked frequently for advice from folks who are looking to get into product management and often send them slightly customized versions of the same thing. I decided to write something a little more comprehensive and share it broadly.
There are a few phases of work for folks looking to get into product management:
Start by learning about product management and what product managers do
Figure out where you want to work and make a list of companies that are exciting to you
Prepare for your PM interviews, and learn how you’ll be evaluated
1. Learn about product management
Product management is different from company to company. It’s worth learning about the different perspectives of product people at different companies, and here is a short selection:
An important part of the process is generating a list of companies you may want to work at by evaluating company size, quality of mentors, your connection to the product etc. Product management varies significantly by product, vertical (ecommerce vs. autonomous car PMs do different things) and individual company so it’s useful to spend time upfront here.
I recommend going somewhere where you think you’ll get good mentorship from people who are both experienced and very strong product managers. I also recommend joining a company which is growing, as a lot of opportunities can arise from growth.
Companies like Google and Facebook have very well respected product management practices, but it can be difficult to get an interview or get through their process without prior product management experience (unless you are earlier in your career where they have great rotational Associate Product Manager programs).
If you want to learn how to run a product development process I suggest reading agile product management which can be a bit dogmatic and dry, but it’s useful to know these foundational elements
Practice questions on the PM interview – it autogenerates a bunch of questions and you can go through them
Analyze products: Spend time breaking down products you like/don’t like – most ‘product people’ naturally do this, and enjoy this type of exercise. I like to break down my analysis into 1) Why does this product exist, what user need is it solving? 2) What do I like about the product? 3) What would I change and how would I change it?
Learn how you’ll be evaluated: Companies hire somewhat differently so make sure that you ask your recruiter or hiring manager about how you’ll be evaluated as part of the interview process. Here are a few dimensions from my experience that I’ve used, and seen used in the past.
My Interview Criteria: There are a few key skills that, I believe, PMs need to be successful and I use them to assess product management candidates. It’s important to have at least one area where you feel like you are excellent and can get that across during the interview process.
Analytical Ability: Run AB Tests, interpret metrics, data informed decisions
Product Sense: System design, uX design
Leadership: Inspire, influence, build loyalty, have empathy
Project management: Prioritize, get things done, make tradeoffs, unblock
Technical ability: Ask the right questions, build trust/respect
Google Interview Criteria:
Product Design: User experience and design
Analytical ability: Fluency with numbers, product metrics
Technical ability: System design, algorithms – earn respect from engineers
Strategy: Business turnaround, go to market
Culture: Googliness, kindness, leadership
Facebook Interview Criteria:
Leadership and Drive: Influence, Self starter, influence teams
Execution: Goals, metrics, prioritization, process
Product Sense: Design, understanding users
Engineering fit interview: Not a technical one like Google, more of a fit interview
Being a product manager is fun, challenging and a great fit for people who like to make things, and like making things in a better way.
Best of luck in your journey and thanks for reading!
I love using tools to make myself more productive and let fewer things fall through the cracks. There are so many great (free) tools available and here are a few of the ones that have helped me the most:
Calendly:Scheduling is one of the biggest time sinks for me. Calendly allows me to share my availability (in time slots that I define) and allow people to schedule time with me without the back and forth usually required. It usually saves me 3-5 emails per scheduled call and I like it better than using virtual assistants like Clara or Byron ($200 per month each). I use the free version which I imagine would fit most people’s needs.
Streak: If you manage any kind of pipeline (sales, investments, recruiting) and use gmail, then I highly recommend Streak. I’ve used it to track potential investments, investors and for recruiting. Streak allows you to have a CRM in your inbox and also scales well to multiple users. It allows me to stay organized, have a record of interactions, and make sure that I don’t let to-dos drop. I use the free version as well, but it costs $50 per month if you’re using it with multiple people or need API access.
Gmail canned responses: I realized that I was very frequently writing the same set of emails over and over again: 1) Scheduling time 2) Making a connection 3) Product information 4) Passing on an investment. I use the Gmail canned response feature to add in the re-used content in addition to the personalized note that I send.
In my opinion, one of the hardest parts of product and general management is drawing insight from the right sources to determine ‘product health’ to identify where to focus, especially when managing multiple product lines.
In my experience I try pull data from three independant, uncorrelated sources to inform where I should focus my effort – the data, the team, and the users:
Data: Design dashboards that give you the metrics at the right level of detail on a daily/weekly/monthly/quarterly basis. Be able to translate data into concrete hypotheses and insights.
Team: The general manager (GM) or product lead of the business is your main source of information, but make sure to spend time with team members and other functional leads as well, so you can validate/invalidate what you hear from the GM. The broader team is also an incredibly strong resource for ideas for new features.
Users & Customer Service (CS): It’s important to maintain empathy/understanding of your customers, even when you’re a step removed from the product.
On a regular cadence (e.g. weekly), spend time reading user reviews, blogs, forum posts etc.
Get quantitative and qualitative information from the CS team about what users are saying about your products over customer service channels, either through a short meeting, or a list of top 5-10 issues each week.
Spend time actually interacting with customers, and responding to them (directly or on forums for example).