My Top 10 Mistakes as a Product Manager for Pley

Few skills is as important for a product manager as self-reflection. It is the PMs job to stop and change when things aren’t working.

I’ve long wanted to put together my top 10 list of mistakes as a PM to try to learn from them in the future. This is that!

Here is that list.

1. Always label experiments versus long-term product bets so teams know what to build and when to kill it.
2. Pour effort only into areas where we can realistically be best-in-class; otherwise, buy or partner with another service.
3. Validate the problem, target outcomes, and success metrics before writing code.
4. Plan distribution so every feature actually reaches the users who need it.
5. Seek out churned or unhappy users and learn why they left.
6. Avoid integrating with big partners who suddently pivots and leave you holding the bag.
7. Spend more time with your users.
8. Stay close to sales and customer success conversations for real-world feedback.
9. Understand customer pain and product market before reacting to competitor moves.
10. Ship fewer things, but demand exceptional quality from anything in your product.

#1 What Is Experimentation and What Are Low-Confidence Products?

It is a mistake to not differentiate between time-limited experiments and low-confidence product development. Treating every idea like a product instead of a hypothesis leads to wasted time, unclear learnings, and blurred accountability.

In Pley, I initiated so many projects, many of them being experiments. We don’t always have the luxury of certainty, so we must validate early and make decisions as we go along (and confidence increases).

However, an experiment should be time-limited. Engineering must be told this early (and often) so they build the tech in a way where they know we are just validating. If the experiment shows it isn’t a good direction, we kill it quickly. Sometimes though projects aren’t time-limited experiments, they are product bets where we don’t have the proof points. These are features we should be proud of, refine over time, and tend to.

TLDR: Make it very intentional and clear what is time-limited (will be deleted if it does not pay off) or what is product functionality (which we intend to maintain forever and refine over time).

#2 Can We Be the Best in the World at This?

It is a mistake to invest considerable resources into things we could never be best in the world at.

At Pley, that was always payments. We saw it as critical to be part of the payment chain, so we get paid. As a revenue share platform, it is core to what we do. However, entire companies which are larger than us dedicate their full team to this. So our payments were never what they could be, and it drained our resources maintaining and improving it. And our users don’t care; payment solutions weren’t why they were our partners.

TLDR: Invest in what you can be the best in the world at. Make intentional buy vs. build decisions. Think long and hard before you build something you won’t be best in the world at, especially as a startup.

#3 Building Too Early

Beginning to build solutions before the problem has been validated, assuming feasibility and analysis are good enough substitutes for real validation.

At minimum, you need to have an idea of what a “good” result would be (in KPIs and outcome), and what a “failed let’s shut it down” situation looks like. Model the basics. Then, go out and validate what you don’t know. Search the internet for people complaining about what you’re solving. Talk to target users, ignore your product, and ask them about their pains.

At Pley, we often launched things very quickly, but it honestly limited our growth. We moved very quickly from idea to production, but not nearly fast enough from production to declaring “success”, “improve”, or “kill”. Additionally, I spent way too little time talking to players.

TLDR: Know what success and failure look like in KPIs, and make sure you have some sort of reason written down why you decided this was a good idea (backed by talking or reading the words of real people who could be your users).

#4 Distribution Is Everything, Even for Established Brands

Not making it a core requirement to push Pley features to players, and failing to consistently drive engagement with our most valuable user journeys across every surface.

Coming from the gaming industry, this one isn’t surprising. What may be surprising is that even though I know distribution is everything in my bones, I still mess it up.

TLDR: Make sure that features you build actually reach their target audience. If a tree falls in the woods, does it make a sound?… It is your job as a product manager to make sure everyone hears your tree falling.

#5 Talk to Your Unhappy Users

Not talking to churning customers and players to learn their pains, because it’s hard, exhausting, and uncomfortable. But that’s exactly where the truth hides. It is so scary talking to unhappy people, especially in B2B. They are hard to reach, what they say is painful, and they will not be interested in talking.

TLDR: If you aren’t talking to churned or churning users as a PM, you have to start. Find ANY way. Pay them. Learn why they left.

#6 Be Wary of Big Industry Names

Integrating with large organizations because their name carries weight, only to find ourselves catching up when they change direction and don’t care about our timelines.

Unfortunately, we did this over and over at Pley. Mostly around game distribution. Big companies (Microsoft, Discord, Google, Meta) look fancy and we fight to partner with them. But even if they’re excited at first, they may change over time. Many times they deployed changes, which broke our platform, and we had to play catchup. And you either kill your integration or change with them.

The cost of maintaining that technical relationship is terribly expensive. But once you tell your customers and stakeholders, killing integrations no longer becomes an option. So think long and hard before jumping into bed with a big organization.

TLDR: Do not hitch yourself to big organizations unless you have to. The cost of doing so is 10x what you expect.

#7 Time with Users Is Always Time Well Spent

Not spending enough time with players to systematically understand their psychology and behavior. Insights decay quickly if not continuously refreshed through real conversations. It became to core to my day to day to talk to B2B customers, and not players.

In the end, game companies live and die by their player experience, even if they have to sell to the studios first.

Words cannot explain how important this is.

TLDR: Talk to users more. It is always time well spent.

#8 Spend More Time in Sales and Customer Success

Not spending enough time with customers in the sales pipeline. I did spend a lot of time with B2B customers, but more time with customers is always time well spent.

Again, words cannot explain how important this is. I just happened to have two customer bases after becoming product lead (B2B game studios and B2C players).

TLDR: Talk to users more. It is always time well spent. True for B2B as well.

#9 Chasing Competitors Only Works If They’re Headed the Right Way

Chasing competitors into product markets before deeply understanding what our own customers want, and before building empathy for their pains.

It was rare, but once or twice we saw what a competitor was doing and knee-jerk began building it ourselves. It made sense to us, and the fact that someone else was investing in it gave us false confidence.

However, companies have entire teams to make it look like they know what they’re doing. If you have worked with a marketing or product marketing team before, you know that it is true. People selling confidence do not always know what is going on. And people building don’t always validate either. Product by “pulling things out of your ass” is tried and true. It doesn’t work.

We can only know what to do when things go bad, by knowing how we got ourselves into the situation.

TLDR: Understand first, then build. Do not assume competitors have validated or done strong discovery.

#10 Hold Yourself to an Uncompromising Standard

Not holding the product to a higher bar, doing too many things at average quality instead of fewer things at high excellence. We should demand greatness from each other and be proud of what we ship.

Occasionally, when trying to move quickly, we said things like “It just needs to work”, or “Let’s fix it later”. But now years later, I wish we never did. I wish anything we declared as a “platform feature” was held up to the highest of standard.

TLDR: Build fewer things, but make sure the quality is sky high. Be the best in the world at the specific thing your users buy or sign up for.