Expectations, surprises, and lots of learning.

Today marks my 1-year anniversary of being a full-time Product Manager.

I did internships, took classes, and read extensively about the topic. But nothing could prepare me for the role like experiencing it first-hand. (Just like parenting)

In some ways it was exactly what I expected. In others, it was a surprise.

But overall, it has been an amazing year.

I hope this personal reflection helps others who are also new to Product Management, or are considering it as a career choice.

What is Product Management?
(For real this time.)

Throughout the whole year my job was

“Defining what needs to be built to delight our users”

This matched my expectations, but doing it effectively was more nuanced.

Sometimes, I wasn’t segmenting my user personas with enough granularity.

Other times, I failed to account for certain requirements.

At times, the messaging wasn’t clearly communicating the product’s value.

However, the key learning from all of this was to

“Keep moving, and adjust along the way”

This became my Product Management ethos.

Working with users

Going into this role, I expected to interact with users so much they’d think I’m their shadow.

I even read that I should be conducting 10 user interviews per week if I wanted to be successful.

Well, I wasn’t. I was barely doing 1 interview a week consistently.

Looking back at the past year, I realize that I had three issues

1) I didn’t scope features well enough

Yes I know. I had ONE job. *facepalm*

After months of struggling to collect user input effectively, I finally learned that I wasn’t sizing the problem appropriately.

It was either too big so conversations remained shallow, or too small that an hour interview was mostly filled with awkward silence.

Once, I started to scope things properly, I was able to collect better user input .

2) I was hung up on finding “cool” features

Many fall into this trap. The allure of finding the next mind-blowing feature is very real.

Over time, I learned that starting with a basic feature that’s flawlessly executed is more important.

Do it consistently, and you win your user’s trust.

Do it iteratively, and you WILL deliver cool features.

(Illustration of Product Development by 

Henrik Kniberg

)

3) I was only depending on 1:1 interviews

Though important, 1:1s are time-consuming, and don’t scale very well. Precious time goes by before getting results.

Plus, with each new product discovery item, the time requirement grows larger.

Eventually, I learned that there are many ways to collect user data like

• reading weekly highlights or docs that user’s publish
• understanding the user’s job better
• asking the user directly on Slack
• sending surveys
• using the product yourself

Depending on the topic, you may choose different methods.

The ultimate goal is to become the main proxy for the user. You should be able to understand them, empathize with them, and represent their needs.

Working with team members

I heard two main points on this topic before starting

1. Product Managers don’t usually build the product themselves.
2. Product Managers need to influence without authority.

Both were true throughout my first year.

There are many key players in a product’s life. Each of them has a unique role in a successful product team.

As a Product Manager, my role is to ensure that everyone is rowing in the same direction.

Engineers

They are the ones actually building the product, so being in sync with them is absolutely important.

Two things helped me build trust with my engineering team

1. Get their help in understanding technical details of the product: I learned so much about Git repo management, Kubernetes, Argo, databases, build systems, and more. This helped me understand the complexity of our product, which helped me keep in mind different requirements and constraints.
2. Include engineers in product discovery: This allows engineers to listen to user feedback directly. Also, it enables them to raise any technical feasibility risks early.

Over time, every product document I wrote needed to include the following for effective development

1. User Stories: convey “why”, “how”, and “what” the user is trying to do.
2. User Needs: strip down requests to the core reasons behind the request.
3. Product Requirements: list the specifications that need to be met.
4. Mock ups: illustrate what it will look like, and validate it with users.

Designers

There’s a lot that Designers do in a product, but two key things stood out to me

1. Running user studies: Designers are experienced in different methods and techniques to extract user feedback, and uncover valuable insights. I learned about diary studies, Kano analysis, and more.
2. Ensuring smooth user flow: no one likes a hard-to-use product. Even an unfriendly login page can scare new users away. That’s where Product Designers save the day by considering the user experience in every detail.

Program Manager

If the Product Manager is responsible for steering the product ship, then the Program Manager is the navigator.

They are your right-hand person in knowing the landscape, uncovering roadblocks, and helping you move around any issues.

Program Managers maintain a birds-eye view of all the organization’s work, and communicate throughout the team accordingly.

Sales

Your product is not going to live to delight customers unless you’re generating revenue. And you can’t generate revenue without sales.

With that comes a natural tension: sales might want to sell products and features that haven’t been developed yet, while product wants time to develop the product with confidence.

The perfect balance is when the two collaborate together tightly. Sales needs to be well informed of the product roadmap and execution complexity. And the product team needs to be aware of all customer engagements and feedback coming from the field.

Marketing

Customers aren’t going to buy a product they can’t understand. Period.

Your marketing team can help you craft messages that are crisp and accurately convey the value of the product.

This may take some iterations before finding the right words, so test it repeatedly.

Share the product messaging with someone new, and see how they respond.

Process and Communication

A lot of time can go by discussing questions like: “is this a bug or a feature?”, “what’s in scope again?”, and “what’s the status?”. The time needed grows with the size of your team, too.

That’s why clear processes and communication are instrumental.

Here are some things that worked for our team

1. Tools for Managing Tickets: whether it’s bugs, feature requests, or planned engineering tasks, they need to be logged systematically. This way you can prioritize work, and monitor progress.
2. Weekly Backlog Grooming: the number of tickets will grow, so you need to regularly comb through them and prioritize.
3. Weekly Planning Meetings: these meetings help set the high-level team priorities for the week. In turn, this helps each person decide which tasks are important.
4. Cross-team Planning: your team might be one of many product teams in your organization. You need to ensure that you maintain a coherent product story as a whole.

Launching the Product

This is a major milestone for any Product Manager, whether a newbie or someone doing this for years.

I was fortunate to participate in a product launch during my first year, and here’s what I learned

Choose your first customer wisely

This may sound counter-intuitive because you just want to find a customer. But finding a strategic partner will be an important decision that will help the longevity and success of your product.

I learned this from the more experienced members of my team.

A strategic partner understands that this is the first release for the product, so it may have some kinks, and they’re happy to provide feedback.

This is a fruitful relationship that will help develop your product further.

Focus on core features that are well executed

Pick the bare essentials of the product, and iterate on them repeatedly to make them flawless.

Test them over and over again with new people for a fresh perspective.

From there, you can include more advanced functionality, or new features based in future releases.

Over-communicate Plans

Releasing a product can be a stressful deadline for the whole team. No one wants be called-on last minute to work miracles to get the product in shape.

It’s important to plan out the weeks before the release with clear milestones. Then, have regular check-ins, so different team members can raise flags early.

Therefore, make sure that the release date gives your team ample time to scope, test, install, and dry-run the product with the customer before the release date.

Charting your path

Many people become Product Managers from different backgrounds: engineering, consulting, finance, and others.

Now you’re a Product Manager. Even though there are some clear responsibilities, it’s still important that you define the role for yourself.

What does it mean to YOU to be a Product Manager?

Answering that question for myself helped me become more comfortable making decisions, testing ideas, and setting-out on my own.

I believe that every Product Manager needs to answer that question in their career.

Because dealing with ambiguity, and influencing without authority, requires leadership and confidence, which you can only feel once you’re comfortable in your own skin.

Final thoughts

Product Management can be challenging, but it’s been the most rewarding role I’ve been in to date.

You interact with people, solve problems, and learn a lot along the way.

I’d like to thank all my great colleagues who played a part in making my first year such a rich experience.

Also, this was my first serious blog-post, so I hope you’ve enjoyed it.

I’d love to hear your feedback, or your suggestions on future topics I can write about.