When I was asked to become the first product manager at my startup I had no idea what I was getting myself into. In fact, I had no idea what product management was. I was asked to take the role because of two reasons, 1) I had already started to take many of the responsibilities organically, and 2) there was nobody else to do it. For the next two years, I learned that not all product management roles are the same, and that being the first product manager truly has some unique challenges.
Key responsibilities of the first product manager are to build and evangelize for the product management process, clarify the roles & responsibilities across functions, establish communication channels and define the tools of the trade.
To be effective in this role requires sensitivity and laser focused clarity- sensitivity because the role often requires redefining the scope of other functions of your company, and clarity because everything appears to be a priority in the beginning.
So how do you get started? Well the first product manager is never really the “first” because in reality, the CEO is. So getting aligned with the CEO, the business, the people and the product is a great place to start.
What is the scope of responsibility for the first product manager?
Becoming the first product manager of a company is a huge accomplishment. Not only does it reflect on your abilities, but it is a tremendous amount of trust that has been given to you from the leadership. So what makes the role of the first product manager different?
The first product manager’s duties go beyond that of a typical PM role. In general, you’ll be making high impact decisions around how product management is done in the company. In practice this means defining key questions such as:
- What does the product management lifecycle look like?
- How will we communicate with our internal teams like UX and Engineering?
- What tools will we use and how will we use them?
- How is the product team structured?
As the company evolves, so will the answers to these questions. However, as the first product manager, you have the opportunity to influence the direction of how product management is done in the company for years to come. One common mistake is to look for best practices and try to implement them from the top down. This is the wrong approach because every organization and product maturity is different. Instead, the best place to start is by looking at how the problem is being solved in your organization today.
By looking at how things are done today, you can take the pieces that are working and build on it. You also build better relationships with your key internal stakeholders through this problem and tackle it together. Product management is often the glue that brings the various teams within the company together, so getting the internal teams involved is a good way to lay a strong foundation for success.
What does the product management lifecycle look like?
When I became the first product manager of my startup, I studied as much as I could on various frameworks for product management but found that most of it was too theoretical and it was hard to put into practice, at least not in the way that was right for my company.
But the product management lifecycle (PML) doesn’t have to be complicated. In fact, the more simple it is, the more likely it will succeed. This is especially true in the early phases of an organization. The main questions you want to answer during this phase is:
- How do we take an idea from planning to launch?
- How do we communicate through the process internally?
- How do we communicate the launch to our customers?
- How do we process feedback and address issues/bugs/complaints?
- How do we continue to improve the product?
The “right” answers will vary based on the maturity of the company and the product. As mentioned before, the objective is not to start fixing everything. Invest time and enegery in conducting due diligence to understand the DNA of the company and its culture. Doing so will help you build a full picture of the current state of product management which will help answer key questions such as:
- How complex is the organizational structure?
- How effective are the current communication channels?
- What is the decision making process?
- What is the culture around product development?
And these questions will help point you in the right direction for building the right PML for your team.
How will we work with our partner teams like UX and Engineering?
The product team often acts as the control tower for other teams. As the product management lifecycle starts to take form, you will find that there are many opportunities to improve the working efficiency across teams. In the past, I have found the biggest challenge to be defining the standards of how one team hands off work to it’s partner teams. Some key questions I had to answer were:
- How do we hand off requirements to UX and Engineering?
- What is the minimum amount of info needed to conduct dev estimates?
- What does the feedback loop look like?
- How does UX hand off design for review and for development?
The bigger your organization grows, the more stable and detailed this process will need to be. In the beginning, you may get by with a more ad hoc method of communication, but this will soon be inefficient as bigger teams will require better knowledge sharing. This means documentation standards across teams need to be established, and the expectations of who will deliver what/when will be established.
What tools will we use and how will we use them?
The process of how we communicate will ultimately be influenced by the tools that you use. Though the tools should exist to support our work, the tools also influence our behavior.
In the early stages, you have more flexibility to experiment with different tools to get the job done, but as you grow, you will want to establish some measure of commonality across the functions. This is helpful when handing off work from one team to the next. For example, if your developers are used to getting design assets and prototypes in Sketch and Zeplin, and you decide to move to Figma, there needs to be a very compelling reason to do so (we’ve made this switch back and forth 2 times before finally settling on Figma).
In my startup we experimented with a lot of different tools and finally settled on a stack that worked well for us.
| The Job | The Tool |
|---|---|
| Task management | Jira |
| Documentation | Confluence |
| UI/UX Design | Figma |
| Flow charts | Lucid chart |
| Excel/Word/Presentation | Google Suite (sheet, doc, slides) |
| Customer Support | Zendesk |
| Business Intelligence | Mixpanel, Google Analytics |
To find that the tools above were the right ones for us, we went through a dozen others. Ultimately, it came down to what our teams enjoyed using (what stuck), and how flexible it was for use across the organization. As with all things, this is not a final list, but a work in progress so there is no need to feel constrained to these tools alone as you outgrow them.
How is the Product Team Structured?
When starting as the first product manager, you are essentially also responsible for building the product team. As the product and company matures, your team will grow. While this is exciting, it will bring with it a new set of challenges such as:
- How is the product team structured (feature based, matrix structure, functional, etc)?
- Which roles are part of the product team?
- Who do the product teams report to?
- Who reports to the product team?
When there is ambiguity around these questions, decisions often get stalled, resources are bottlenecked and there is a lot of context switching. This is why as the scope of the work increases, it is worthwhile to invest time and energy to align how product teams will be structured across the company.
Conclusion
The role of the first product manager is much more broad in scope because it requires you to lay the foundations of how product management is done in your company. For me, the opportunity to become the first product manager was one of the best ways to learn and grow in my career as a product manager and I would encourage anyone who is in a similar situation to embrace the role and run with it.
