Why I Started the Product Manager HQ Community

Many people are often curious about the backstory behind kicking off the Product Manager HQ community so I thought I’d write a quick post outlining some of the initial thought process.

My very first Associate Product Manager role was at a company called Kabam, a web / mobile gaming company that primarily worked with Hollywood IPs, helping to make games for legendary franchises like the Godfather, the Hobbit, Fast and Furious, Marvel, Star Wars, Transformers, etc…

I joined the company in it’s hyper growth phase (it scaled from 300-800 employees in the 2 years I was there) and like many first-time PMs, I was thrown into the fray with very little guidance.

The PM group hadn’t established a formal onboarding program and each PM seemed to run their games / P&L differently, so the first few months were a struggle for me to establish a baseline of whether I was “doing product management correctly.”

Shortly after I joined the company, Kabam became one of the very first massive publishers to make the crucial strategic shift away from web into mobile. As a result, many of the PMs were entering unfamiliar territory where existing web product development processes started to break down when applied to mobile (i.e. release cycles were much longer due to Apple’s stringent 1-2 week build approval process).

Since everyone was busy adapting to mobile and putting out their own fires, it was difficult for me to find a mentor within the company who would be able to dedicate time towards helping me grow into the product role.

Secondly, our product teams regularly collaborated / synced for product reviews which helped to standardize certain practices, but given this was my first product role, I was always curious how product teams at other companies might have approached solving the same problems we were facing as a company.

I chatted with a few product manager buddies at other companies and realized that I wasn’t the only one facing these problems. Other new PMs were having a hard time:

1) Finding a product mentor outside of the company

2) Finding a peer group of PMs to chat with about best practices / ideas

To solve these problems, I first turned to attending as many product events in the city as I could find. However, I quickly realized that these one-off interactions with attendees once a month weren’t enough to solidify the trust necessary to develop mentor/mentee relationships or establish a support group that I could turn to whenever I needed advice.

Additionally, I often came across time-sensitive issues at work and there wasn’t a synchronous medium that I could tap into in order to get immediate feedback.

All of this was happening around 2013, and as luck would have it, an interesting company called Slack had just pivoted into a real-time collaboration platform (the Slack we know today). I fell in love with the Slack platform as soon as I started using it, and realized that it would be an amazing medium to run a live community.

When I first kicked off the community on Slack, it was free to join and I seeded the initial 10-20 members with product manager friends. 

0-200 members:

In the early days, I would DM (direct message) every single member and start conversations to befriend them and learn about what products they were working on. Between a typeform that people had to fill out to join the community and a mini google spreadsheet CRM that I used to store information on each member, I had a nice mental map of who I should be connecting to whom.

I likened a lot of this initial community building to an experience of attending a cocktail party. Think of the times where you’ve walked into a party solo and awkwardly tried to make your way into a conversation circle – frankly, that experience sucks. Now contrast that to a cocktail party where a friend of yours knows everyone and pulls you into circles while saying “Hey everyone, have you met my friend _________?” It’s a much more accommodating experience, and you’re likely to have a better time.

If one member told me about a problem he/she was having when PM’ing an enterprise SaaS product, I would find another member working on a similar product, introduce them to each other, and ask them to both chat about their issues in public channels so that other people could learn from their conversation. To help kickoff conversations and engage lurkers, I seeded questions in public channels (i.e. “Has anyone here tried any product roadmapping tools? What were your favorite ones?”) every single day.

200-1000 members:

At around 200-400 members, I started to see more word-of-mouth growth as members started referring friends and colleagues in the industry to join the community and conversations started to organically happen daily without much input from me.

Personally welcoming every new member in the community became a bit overwhelming (especially because people joined from different time zones when I might be sleeping), so I began to use tools like Zapier and Slack integrations / bots for more sophisticated and automated onboarding messages.

To help engage the community, I also reached out to specific “power user” members who were chatting daily and asked them if they would be interested in becoming community moderators. I created a private group for these moderators, set some light guidelines, and trusted them to help engage with the community and let me know of any “bad behavior”, i.e. spammers or recruiters.

As a solopreneur who was so used to doing everything myself, establishing this moderator group was one of the most important lessons for me in terms of learning to let go / not trying to do everything myself and distributing responsibility amongst the community.

1000+ members:

At around 1000 members, I began to notice a trend where over 90% of new members joining would churn after the first few weeks (Slack provides a weekly report of which members become “inactive”). A large part of this was because joining was free, so many people joined out of curiosity and left shortly after. I suspected this trend was also happening because the community was now large enough where conversations were happening daily and it probably became quickly overwhelming for new members who had never intended to seriously engage in the first place.

To counteract this, I replaced my typeform with a new landing page / Gumroad plugin and started charging a one-time lifetime membership fee of $25 to weed out inactives and people who weren’t serious about participating in the community. After instituting the paywall, the churn trend completely reversed.

To help justify the $25 one-time fee, I made sure to include plenty of benefits such as instituting bi-monthly AMAs (ask me anything) with product leaders and working with product conferences / events to negotiate large discounts for community members. The community has since featured AMAs with well-known product people in the industry including Ken Norton (Product Partner at Google Ventures), Josh Elman (Partner at Greylock Partners), Punit Soni (Former CPO at Flipkart), Alexandra Cavoulacos (Co-Founder at The Muse), David Cancel (CEO at Drift), and Ellen Chisa (VP of Product at Lola), amongst many others.

The thing that brings me the greatest satisfaction in all of this is the value that I’ve helped to create in the product management community.

In-person meetups around the world happen organically through initial interactions in the community, and our last San Francisco meetup (which was supposed to be with a small group of PMHQ members) blew up on Facebook and brought in 200 aspiring / current PMs to fill up a local bar. Large enterprise companies such as Intuit have even onboarded their entire 200+ global PM organization into the community and continue to onboard each new cohort of PMs every year.

Over the past few years, I’ve lost count of the number of members who have landed jobs from the community. (I try to save as many screenshots of these moments as I can in a folder on my desktop labeled “Why This is Important”.)

And lastly, I’d like to think that product organizations worldwide have gained real insights into how other teams think about product and have shipped better products as a result.

Venture Capital and Product Management

Ever since entering the venture capital industry 8 months ago, I’ve been thinking about how best to cross-pollinate venture work with my previous product experience (Even going as far as to guest-speak on the #1 most listened product podcast about how Venture Capital is Product Management).

In my first post, I discussed how I first attempted to codify the qualities of a good VC. This step was important so that I could begin mapping PM skills / workflows to VC skills / workflows and look for overlapping opportunities.

At a sky-high level (reiterating: sky-high level), you can imagine product management to break down into 3 core buckets of:

Product Planning

All the user research / needs gathering / synthesis of qualitative & quantitative data that helps inform what product / features should be built.


All of the roadmap planning / sprint planning / spec writing / launch planning / cross-functional collaboration that gets the product launched.

Post-launch Iteration

The ongoing planning & execution necessary to keep successfully improving and growing the product post-launch.

If I map this to venture capital, I imagine it to look something like:

Product Planning = Sourcing

Creating deal flow through outbound sourcing (researching industries and doing cold outreach, attending events / demo days, hosting office hours at accelerators, etc…) or inbound sourcing (referrals, inbound e-mails, people pitching you at a party, etc…).

Execution = Diligence / Executing the investment

Filtering through sourced companies by undergoing deeper diligence (getting to know the founding team, deconstructing the product, digging into metrics, looking through historical financials if there are any, competitive analysis, determining customer love, etc…), negotiating terms, proving value-add to win competitive rounds, executing the investment.

Post-launch Iteration = Supporting your founders

Working with the founders to support them and help them succeed in any way possible (board meetings, strategic advice, helping them hire, finding them customers, guiding them on product strategy, thinking through growth strategies, etc…)

Tactically, here are a few random examples (these examples aren’t too structured so bear with me) of cross-pollination that I’ve thought about or tried so far:

Roadmap: I started by creating a personal roadmap outlining the VC skill-sets I wanted to improve throughout the year. I’ll need to regularly re-visit this roadmap in order to re-prioritize where I want to be focusing my time.

Venture Backlog: I’ve created a backlog of venture projects (for myself and a few members of the venture team) that I cost and prioritize so that I can actively work on top-priority projects during any rare down-time I have.

Sprints: I need to do a bit more thinking about this one. It’s easy to fantasize breaking down my workflow into sprints / sprint tasks but my weeks can be spontaneously unpredictable, especially if we’re considering an investment where the funding round is moving quickly. This leads me to believe that the traditional product sprint cycle would break far too often to be accurate or even necessary.

Specs: It’s not an exact parallel but I’ve tried to structure writing my investment memos as if I were writing product specs. There’s not as much team collaboration around memos (we’re generally expected to have filled out the majority of our memos with our own points of view) but we’re expected to be just as thorough and think through all “edge cases.”

UX: I’m always looking to improve the “user experience” for founders. I never want a founder to leave a meeting feeling like they’ve wasted time with me. I’ve been experimenting with various methods of feedback – one passive strategy was creating a Typeform that I link in my e-mail signature. Lot of clicks but no responses yet (I may shift to simply linking to this Typeform in my rejection e-mails to founders)

My e-mail signature

TBD: I’m going to keep this a living post and update accordingly as I experiment with more cross-pollination in the upcoming months

If you want some more inspiration around the importance of cross-pollinating, check out Scott Adams’ book “How to Fail at Almost Everything and Still Win Big.” For those who don’t know, Scott is the original creator of the Dilbert comics and this book is a peek into his life journey from his humble origins into the comic superstar that he is today.

It’s a great feel-good story: a seemingly average underdog overcomes potentially career-ending voice & hand health issues, works consistently on nights/weekends at his craft, and finally gets the break he needs.

More importantly, there are a few pieces of “career advice” that he sprinkles throughout the book. One particular non-traditional recommendation he gives is to forget about becoming the best at one specific thing and instead become very good (top 25%) at two or more things.

What’s the First Thing You Do When You Come Home?

A few days ago, I was enjoying coffee with a new friend I had met over the Internet when she proceeded to ask me what my hobbies were.

This question has always been tough for me to answer. I enjoy casual activities (I occasionally play guitar, sing, work out, play sports, delve into nature, etc…) and I have nothing against “hobbies,” but if I were 100% honest about it, I spend the majority of my time doing things other people might label “work.”

If I’m not focusing on venture (studying new industries, talking to founders, helping my existing portfolio companies), I’m probably looking for ways to improve Product Manager HQ or using my remaining time to learn new skills / educate myself on new topics.

I’ve often contemplated taking Jason Lemkin’s (SaaStr founder) approach of outright answering these types of questions with “I have no known hobbies.” #noshame.

One question I like to ask people instead is, “What’s the first thing you do when you get home?”

People tend to follow very standard routines / habits and the first thing they do when they get home (assuming they are working some sort of day job) oftentimes dictate how the rest of their night will go – whether that’s sitting at their desk and typing Netflix into a browser, opening a book, heading to the gym, etc…

I don’t believe that people can change their behaviors easily (there’s a reason most health / fitness apps don’t end up dramatically influencing any kind of diet or exercise behaviors) and understanding their routine actions when they come home provide a much better glimpse into what kind of person they are or aspire to be.


How the Economic Machine Works

After finishing my previous post referencing Ray Dalio’s Principles, I ended up digging around the web and came across this 30-minute gem where Ray Dalio uses extremely simple principles to explain how the economic machine works.

The video is nicely narrated & visualized – definitely worth the 30-minute watch.

Pain + Reflection = Progress

One item that’s long been on my reading bucket list is Ray Dalio’s Principles, a 3-part 100+ page living document that outlines: the importance of principles, Dalio’s most fundamental life principles, and his management principles.

Ray is probably most well known for founding Bridgewater Associates, one of the world’s largest and best-performing hedge funds, known for it’s cult-like culture.

Empathy and kindness aren’t a top priority there, says a former Bridgewater employee. The firm’s culture of absolute candor is designed to strip out emotional considerations and emphasize cold, Vulcan logic in all decision-making—the thin-skinned need not apply.

-Quoted from an NYMag piece

If you’re curious, you can read more about Ray and Bridgewater in this Fortune piece here.

A few weeks ago, I finally started digging into Principles and a few pages in, one particular section stood out almost immediately. I’ll paste it in its entirety here:

It is a fundamental law of nature that to evolve one has to push one’s limits, which is painful, in order to gain strength—whether it’s in the form of lifting weights, facing problems head-on, or in any other way. Nature gave us pain as a messaging device to tell us that we are approaching, or that we have exceeded, our limits in some way. At the same time, nature made the process of getting stronger require us to push our limits. Gaining strength is the adaptation process of the body and the mind to encountering one’s limits, which is painful. In other words, both pain and strength typically result from encountering one’s barriers. When we encounter pain, we are at an important juncture in our decision-making process.

Most people react to pain badly. They have “fight or flight” reactions to it: they either strike out at whatever brought them the pain or they try run away from it. As a result, they don’t learn to find ways around their barriers, so they encounter them over and over again and make little or no progress toward what they want.

Those who react well to pain that stands in the way of getting to their goals—those who understand what is causing it and how to deal with it so that it can be disposed of as a barrier—gain strength and satisfaction. This is because most learning comes from making mistakes, reflecting on the causes of the mistakes, and learning what to do differently in the future. Believe it or not, you are lucky to feel the pain if you approach it correctly, because it will signal that you need to find solutions and to progress. Since the only way you are going to find solutions to painful problems is by thinking deeply about them – i.e., reflecting – if you can develop a knee-jerk reaction to pain that is to reflect rather than to fight or flee, it will lead to your rapid learning/evolving.

So, please remember that:

Pain + Reflection = Progress

When I first glanced over that 3 word formula, my mind immediately raced through all of the recent painful junctures in my life. While I hope to never revisit any of those specific situations again, I can’t help but agree that those times of pain spurred some of the most pivotal changes that positively influenced my well-being.

Ironically enough, now that life has re-stabilized towards a healthier baseline, I sometimes find myself worrying that I’m not creating enough pain in my life to push through existing boundaries.

As my friend Ray and I often jokingly say to each other, “You can’t get out of bed if you’re sleeping in silk sheets.”

Tim Ferriss, one of the world’s leading self-development gurus, has previously recommended that everyone should intentionally re-create painful situations every once in awhile, whether that be intermittent fasting, or sleeping on the sidewalk outside your home for the night.

The thought process of creating these mini-scenarios is is 2-fold:

1) You’re forced to leave your comfort zones which drive you to be more resourceful and think creatively.

2) You break the cycle of hedonic adaption (the observed tendency of humans to quickly return to a relatively stable level of happiness despite major positive or negative events or life changes) and become more appreciative of your present situation. Additionally, you are less likely to feel as negatively impacted when something “bad” happens in your life.

It sounds masochistic but one thing I’d like to explore more of this year is how I can methodically create more pain in my life.

Smells like a potential side project idea…