Product Manager - Right Way!!!

5 Things To Know Before Getting Started

If I could travel back in time, here are five things I would tell myself.

Be Mentally Prepared

You will be doing lots of things for the first time and likely no one can guide or mentor you. At most early-stage startups, CEOs or founders are the product managers until they find themselves struggling to keep track of what exactly their teams are building while juggling other responsibilities like fundraising and hiring.

In my case, I report directly to the CEO. There’s no VP of Product or anyone else with more product management experience in the company. We didn’t have any documentation, processes, or guidelines to refer to. And we were hardly able to stay on top of the growing customer demands.

I quickly realized that we have to make changes, not just to take initiatives by myself, but to get buy-ins from the whole team to try things that have never been done before.

Compared to other functions, the product is often considered less specialized and less well defined. Before the first product manager joins the company, engineers are already building features. And because product managers don’t code or design, why a company needs a product manager is less obvious.

Therefore, it’s extremely important to build trust, secure quick wins, and add value before attempting to transform the organization. I will talk about how to secure quick wins and add value in a minute.

But first, make sure that you talk to everyone in the company. Learn about the culture. Analyze the biggest challenges and unexploited opportunities. And talk to customers to become the go-to person for customer insights and product directions.

Being the first person in the product team could be daunting. You seem to always have an endless to-do list. There likely isn’t a roadmap, sprint planning, standard quality assurance procedure, or decision-making process across the company.

Be Resourceful

Ask people, read a lot, and build your panel of experts for questions, best practices, and feedback. Focus on people who can give you key insights or act as your sounding board.

I got a lot of valuable insights about team structure, resource allocation, and project management process from my PM friends in various industries and stages of companies. I also reached out to a few heads of products in more established startups and learned a great deal about how they scaled their product teams.

As we started to take on more projects and deploy our solutions in the field, it became more and more difficult to track feature changes and stay focused.

One day while I was chatting with an engineer, I realized that I can make people’s lives easier: Clearly communicate features and requirements ranked by priority so engineers don’t have to go back and forth and can instead focus on their work.

Provide the business development team with well-defined product marketing collaterals to facilitate conversations with potential customers and ensure focus on scalable core products aligned with our roadmap.

Finally, make sure to focus on the highest value product initiatives. You will face many difficult decisions:

“We need this project to hit our quarterly sales target but it requires new features that deviate from our roadmap.”

or

“We are not hiring fast enough. Should we allocate our limited resources to code refactoring or building new features that customers requested?”

There will always seem to be more things than we can possibly accomplish. I was once told by a product lead at Google that a product manager’s most important job is to define requirements clearly and help the team prioritize, focusing on the highest value initiatives.

It’s important for an early-stage startup with limited resources. But it’s also true for larger organizations because wrong prioritization could lead to a massive waste of engineering resources.

Waves Of Changes

Being the first product manager is challenging but it also means that you will have a tremendous opportunity to shape the future of the company. It’s tempting to start with highly visible initiatives like strategic planning or organization changes. However, even though product management has both tactical and strategic levels — we need to focus on tactics initially.

I found the concept of “waves of changes” proposed by Michael Watkins in his book, The First 90 Days, particularly relevant here. The core idea is that if we keep changing things then we don’t know what is working and what is not. In addition, as previously mentioned, we also need to observe and build trust before making major changes.

First Wave: Start With Managing Projects Well

This is where you can make a big difference initially and secure early wins. Most startups are scaling like crazy at this stage. It’s too much for founders to track ever-changing features and communicate with customers while managing a rapidly growing engineering team.

You’ll immediately become a major contributor if you can clarify customer requirements, prioritize engineering tasks, manage feature changes, and follow through the progress all the way to deployment. This will also build momentum and help advance your longer-term goals.

Once you have critical projects on track and make priorities clear for the entire team, it’s time to address the other end of the equation: to manage the project initiation process and help sell more products.

That includes crystalizing positioning and product marketing messages, standardizing project proposals, converging product offerings, and creating a consistent pricing strategy. Building products in an early-stage startup is an iterative process from an initial idea, an MVP, testing, gathering data, (pivoting and repeating all steps before), modified MVP, eventually to a scalable product.

1. Always go back and refine the product offering. Make sure that the sales team is up-to-date so you won’t end up managing projects with growing custom requests.

Second Wave: Build Defensible Advantages — Process, People, And Culture

Now we have priorities under control and went through the project initiation process with sales/customers and project execution with engineers. How do we instill new patterns of behavior in the organization?

A few things to consider:

1. Documentation

Start to build a list of documents you have and need. These could be sales or technical, internal or external documents, ranging from on-boarding comments, to a troubleshooting guidebook, to a user journey map, to spec sheets, to the product roadmap. Make it easy to find and available to everyone so people don’t need to reinvent the wheel. Keep it simple and updated because there will be ongoing changes. The purpose of documents is to facilitate communication and increase productivity. So be aware of having too many documents.

2. Process

Define the right process to repeatedly deliver successful products. As a company scales, simple things become difficult. Communication is the best example.

How do we make sure that the right people are involved in decision making?

Who is responsible for doing what?

The process can range from daily standup meetings, sprint planning, project initiation, product discovery, to quarterly roadmap discussions. There’s no one-size-fits-all approach. And you will definitely make mistakes when you roll out these processes. It’s fine that we don’t come up with the perfect first roadmap. Continue to improve and the second version will be better.

3. Organization

Even with the right documentation and process, there could still be inefficiencies in the organization: many dependencies, meetings without constructive outcomes, or even clashes among teams. Then you might want to think about building strong product teams.

Product teams are cross-functional teams that own a product or a substantial piece of a product. They are tasked with solving specific customer problems instead of just building features.

Ownership and responsibility allow the team to feel empowered. And they naturally work together within each product team because they focus on OKRs (Objectives and key results) on the product team level rather than functional level.