Product Management: Zero to Hero in 90 Days

Do you think you know what product management is after reading a couple of books and blogs, or listening to podcasts? Can you confidently say that you work “agile” after running through a few sprints? If you do — the way I used to — then prepare to have your mind blown.

That’s an exaggeration, of course. But the journey from a textbook education to IRL product management is transformative, especially if you undergo it in 90 days.

Becoming a product manager

I joined Postlight as an Associate Product Manager out of graduate school. Prior to grad school, I hadn’t even heard of the profession of product management. I picked up everything I knew about product management in classes, through case studies, and with hands-on projects. By graduation, I felt confident that I could found a startup and build amazing products immediately. 

But a textbook education gets put to the test with on-the-ground training. The reality is, it is very hard to “get” product management with no practical experience. I found an opportunity at Postlight as an Associate Product Manager and embarked on a 90-day plan with three phases: learning, collaborating, and then taking full ownership. The process guided me through the transition into the “real world” of product management. 

Here is briefly how my PM journey looked:

Phase 1: Learning

• Big question: What’s in a product?
• Tasks: Create a product documentation to understand each element of the product.

Phase 2: Collaborating

• Big question: How to effectively build a product? 
• Tasks: Develop user stories and conduct QA.
• Product team interactions: Provide feedback to the product team.

Phase 3: Owning

• Big question: What to build next?
• Tasks: Explore prioritization strategies.
• Product team interactions: Start planning with the product team.

Throughout these three months, I realized that my understanding of product management and agile had been on a superficial level. It takes hands-on practice to truly understand the essence of these principles.

Two concepts stuck with me especially: the power of user stories and the Agile Manifesto.

The power of user stories

The first thing that challenged my thinking was user stories. Before, I thought “user story” was just a format for framing scope: “As a [type of user], I want to [perform some task], so that [achieve some goal].” Sure, anyone can write this. But what I wasn’t getting is how a well-written user story can bring multifaceted benefits. 

First, a user story is a communication protocol. To write an effective user story, you need to know who your audiences are and what they need to hear. It’s not a long-form story jam-packed with as much detailed information as possible; it is about what the engineers or designers need to know so they are clear about what to do. 

One way to improve a user story is through continuous iteration: Each time a question is raised regarding your story, take a step back to question if it is caused by something ineffectively communicated, then improve on that. 

Second, a user story defines a shippable unit of work. While there are different approaches to scope work at different granularity levels, the core concept of a user story is that it describes a shippable piece of work that brings value. With this in mind, every story should potentially be shippable. This brings multiple benefits: Engineers get clarity of depth of development work, and QAs and PMs get the ability to validate each story independently.

And finally, a user story clarifies the definition of “Done.” The biggest challenge of a story is defining its acceptance criteria. What should or shouldn’t happen? What happens before, during, and after an action? How we align on work being capital-D Done all depends on well-defined acceptance criteria that answers the above questions. 

The Agile Manifesto

In an early conversation I had with my manager regarding agile practices, he commented: “People think they operate ‘agile’ when they work in sprints.”

I was shocked. “That isn’t agile?” But he answered: It is and it isn’t. He showed me the Agile Manifesto. I had read about this before, but until I actually worked as a product manager, it was just words. Now I started to comprehend the meaning behind it and truly appreciate the value of agile. Two of the four principles resonated with me especially:

Individuals and interactions over processes and tools

Whether you work in sprint, kanban, or scrum — and whether you do standup in person, over video call, or on Slack — the success of your product eventually depends on how the team works best together. All of these processes and tools are just there to facilitate, and whatever works the best for the team is the best process or tool.

Responding to change over following a plan

Coming from a hardware engineering background, I was used to product planning in the span of months or even years, working things in a very Waterfall-like manner. As I’ve gotten to see how fast changes can happen for a software product, I’ve started to shift my way of thinking from detailed planning to high-level guidance. Most importantly, I’ve learned to use feedback and iteration for continuous improvement on the product.

The journey of improving at product management is never done. But by moving beyond textbooks and practicing the principles at its core, like me, you’ll be shipping great products in no time. 

Tannah Geng is an Associate Product Manager at Postlight. Want to chat about product management or great products? Drop her a note at tannah.geng@postlight.com.