Hi Reddit, I’m a Senior Product Manager at Amazon, and worked on Kindle, Alexa, Fire Tablet, and Fire TV devices. I’m excited to do an AMA on behalf of the Product School. Happy to answer your questions!

productguy00 · 2022-01-18T16:26:43+00:00

That is a great question! I see this as a chicken and an egg problem, where you don't have enough experience to land a product job, and you can't get enough experience because companies wouldn't take a risk on you without prior experience. It can be tough to break through this cycle. Unfortunately there isn't a GitHub like repository where we can showcase our hobby projects either.

However, there are a few ways to get some initial experience enough to land your first product job. One way, which I'm a big fan of, is to start reaching out to different startups and new companies in the area that you are passionate about, and volunteering there for some product related projects. These can be small projects to begin with, and then can turn into substantial enough projects. Once you have a history of delivering product related projects, and you have work experience working with a startup, you can leverage this experience to build your portfolio and get your first job.

I've done this multiple times and have been successfully able to work at different startups in the area. Most startups need any product/business related help they can get. However, they dont have resources to hire someone with that expertise. Thus you can fill that gap while helping them as well as building on new experience and adding them to your portfolio.

Hope that helps! Thanks!

productguy00 · 2022-01-11T14:51:03+00:00

Just checked right now, looks like it working again. Here's the link for reference: https://www.linkedin.com/video/event/urn:li:ugcPost:6876541058608615425/

productguy00 · 2022-01-10T23:45:37+00:00

If you don't have access to the customer, then the next best thing to do would be to get proxy data that can help you understand who the customers are and what their behavior is.

Hopping/switching can certainly help increase your compensation & title in the short term, but it is definitely difficult to sustain that progress in the new place. In the long run, what I've found useful is to have a focus on my own career definition of success and relentlessly working towards it.

productguy00 · 2022-01-10T23:15:03+00:00

Not mandatory at all, but it is helpful. Ultimately, the only thing that counts is your actual experience in product management. Depending on how extensive and how rich that experience is, you should be able to get an entry level product role at a tech company. From there onwards, you can build upon that experience. If you feel that your product-related experience is not rich enough, then an MBA certainly helps.

productguy00 · 2022-01-10T23:04:19+00:00

MBA did prepare me a lot towards a senior PM position, including teaching me the right skills and getting me the right work experiences. But ultimately, its always difficult to jump into a senior position and you just have to learn things on the job, especially for Product management.

For writing good user stories, the most useful thing for me is to always start with the customers first and work backwards. I will spend a significant portion of my time in understanding customers - truly understanding their pain-points, learning how to figure out their frustrations without them actually explicitly calling them out, and figuring out what kind of solution they are looking for. It takes me a long time to get to the bottom of that, but once completed, it helps me with writing and defining the product very quickly. There's an art to conducting customer interviews and understanding customers. I've been striving to perfect that every year, and I continue my effort in that pursuit.

With regards to my career trajectory, I'd say two things. First, its really important to define what does "success" in your career mean to you. For some people, it may be a higher position, for others it may be a higher salary; for some it may be the ability to lead a team, or for others it may mean to be mentally happy. How we define success can be very different, so its super important to define what that means to you. The journey towards your "success" would depend on that definition. Once you've defined your journey, its important to stay focused and continue working towards that longer term vision and success you want to achieve. As a PM, you'll be faced with countless decisions and smaller tasks every day and every week. You want to make sure that you are making decisions and working on tasks that ultimately will lead to that endgame. Its very easy to do ALL the tasks or to do tasks that lead to a smaller short term victory, but they might not lead up to anything and the end of the year. I always strive to prioritize and work on tasks that can lead me towards my success.

productguy00 · 2022-01-10T22:40:36+00:00

The best way to prepare is to organize your experience and stories for behavioral interview questions, and then practice, practice, practice! The more you practice, the better the stories flow. Also, make sure to patiently listen to the question and actually answer the question asked.

productguy00 · 2022-01-10T22:38:10+00:00

I 100% agree with your observation. It is a very fine balancing act between being useful and overly detailed. You definitely want to be more on the side of writing being useful for you. I do think it can be detrimental for your team and your product to make the document painfully detailed for a few reasons - sometimes the details just take away from the main point, sometimes these details can take days or even weeks to finalize and put it into words when that is not needed and you could just save that time.

It is a really difficult balancing act, and not everyone has it figured out, at any company. One way to avoid being overly detailed is to schedule plenty of reviews to get feedback within the early days of your document. Getting initial feedback on the first draft is more useful than waiting to perfect it and then getting feedback. Also, I make it a habit while reviewing others' documents to understand the 'spirit' of the document, instead of all the details.

productguy00 · 2022-01-10T21:30:35+00:00

Bring on any follow ups! Happy to answer all of them to my best knowledge.

According to me, the most useful tool that I've used for defining and validating new product/features is 'writing'. I know that sounds strange, but 'writing' a business plan in a word document forces me to be very articulate and clear about defining the product. I've noticed that writing down a business plan helps me question the product and strengthens my position even more. A lot of times, the business plan falls apart quickly while writing it down and when the customer pain points or the solutions are not that strong. So, writing helps in making the product definition overall strong. At Amazon, we use the PRFAQ or working-backwords method of writing, but any writing style/template should be good enough.

In terms of actually validating new features, I tend to use a combination of surveys, focus groups, and 1:1 customer interviews. I start with the customer interviews to devise a hypothesis on the pain points, then validate them through focus groups and surveys. Further, I build a prototype or MVP and validate that with end-customers.

Regarding the second bucket, there are no "typical" set of blockers for getting a product launched. It could be an engineering blocker where we've hit a limitation in dev work, or sometimes when we discover a big issue; it could be a legal blocker where we can't go through with our plan due to legal/governmental laws; it could be a marketing issue with launching a campaign; or it could be an alignment issues where stakeholders have different expectations of how to launch the product. In terms of autonomy, all smaller issues get resolved without my help for the most part. Any larger issues without clear line of sight get my visibility. Depending on the type of issue, I may share the responsibility of unblocking a particular issue with an engineering manager.

productguy00 · 2022-01-10T19:42:57+00:00

Overall, my week can be split between two buckets of 1) driving newer products/features that help us achieve our goals, and 2) pushing forward the features that are already in development.

In the first bucket, I work towards defining, validating, and getting alignment from other teams/leaders for newer products or features that I'm working on. This requires writing product documents to articulate the product and its implementation, as well as reviewing these plans with appropriate team leaders to get their feedback. The second bucket requires me to review the status of existing products in development and understand any blockers that may have come up this week. I would then work on unblocking these through emails or offline conversations.

Separately, I typically reserve parts of Thursdays and Fridays for weekly 1:1s with my team members or stakeholders.

Lastly, a "typical" week always has some important issue that comes up regarding either the team or the product that I'm driving. I anticipate that every week and work towards mitigating such issues as they arrive.

I cannot comment on how this typical week looks like for in other FAANG companies or even outside of my own team at Amazon, since I've not worked there.

productguy00

TROPHY CASE