Product management solitaire: Things I do to keep my product skills sharp off-work

Product management is part of my identity: I've been practicing it for over 13 years and it's so fulfilling ,important and its principals impact the way I think and act. One of the most exciting things about product management is that as a discipline it's pragmatic and ever-changing (frameworks evolve, new paradigms are introduced and industries that require different form of thinking emerge) but at the same time product management leans on solid foundations: empathy, humanization, market fit, problem statements, prioritization, solutions, measurements and more.

Over the years, I found that working in product-centered organizations immerses me in learning specific user groups, understanding their pain points and develop empathy towards them. At some point, the team and I get so good at product discovery and delivery that we enter a state of flow - every professional member of the team, engineering to design to analysts act in harmony to deliver product solutions based on true needs and optimized processes. It is this point utopian state that make me feel a bit uncomfortable.

Our brain loves heuristics and automated thinking: In order to reduce cognitive stress and allow ourselves to focus on bigger and important things, our brain spends a lot of energy up-front to learn different situations and creates automated responses and behaviors and from there it's auto-pilot until the next set of variables arrive. For example: We spend a lot of time, effort and brainpower building a product roadmap and building delivery workflows - once we do the process is set on rails and we start the sprint-to-sprint-epic-to-epic dance. While this repetitive behavior is what makes us great professionals and masters of our craft, it's can also be restrictive in terms of our ability to think outside our (very nice) box.

About three years ago, I felt that in order to evolve professionally I need to practice product management outside of a work setting. Back in the day, my goal was to experience other product management frameworks hands-on so I can import learnings back to my work environment and elevate the team. What I ended up with was much more than that - it became a series of habits that is helping me improve my craft and that is what I want to share with you in this post.

I named my exercise time "product management solitaire" after the version of the card game Klondike that got popular after shipping with an early version of windows. In my mind, those off-work product management exercises are more game than work and are part of my personal time (In games, 'Solitaire' often refers to a single-player even though one of them involve other people).

above - screenshot of Klondike Solitaire that shipped with Windows 3.11. Robot card back was the best.

plan a product, then build it

If I could highlight only one thing out of everything I do to improve my product management skills off-work, it would be building your own product. Building something yourself isn't necessarily about the end result or releasing something to market - it's more about the journey and thinking that goes into building something from scratch ¹. From ideation through research to an actual product with everything that goes in between.

Building something new starts with a good problem statement, a pain point for a specific person or group of people. Sometimes it even start with a statement: "I check my email too much, it feels like pulling a lever in a slot machine", "I read a lot of books but I'm not retaining a lot of the knowledge", "I spend a lot of time resisting buying video games and it's cognitively taxing". After some time, those type of statements turn into personas, problem statements and user stories. Early on, I'm trying to get a focused, easy to explain definition of why I'm building what I'm about to build and for whom.

After understanding the problem statement I approach the new product using the same product frameworks I'm familiar with, or sometimes even test out new models I read about and excited to try: Setting KPIs, key metrics, what does a minimum viable product look like, how can I test an early and get a product market fit - those are some of the questions I'm investing time in early on and working my way from there.

Let me reiterate: The goal of building something is practicing your product management thinking on real-world problems. Naturally, the more you get your daily reps in and spend time developing a problem statement the more you'd want to actually build it - but it's totally fine if everything starts and ends as a rough program or even on paper!

More often than not, I'll code a rough version of the product for some extra hands-on practice. Other than programming experience, full-stack developing a product is great for learning new technologies and frameworks. More importantly, it helps me see development from the engineers' point of view (to some extent). Coding also gets me a better idea on what it takes to scale and how each component of the technology stack works. Especially in areas like DevOps where I don't get much exposure to at work (seriously DevOps people, you are doing sacred work).

Here's an incomplete list of things I've built during the past year -

• A terminal-based Twitter client for mindful use (I wrote a bit about it here)
• A program that automatically presents weather and checks email every time I open my terminal window in the morning (part of my morning ritual automated)
• An pen-pal club for Animal Crossing with matchmaking based on age group - this one's live
• A machine learning based tool that reverse engineers how automated candidate tracking systems work

practice 'product sense' outside your comfort zone

When you apply for a product position at most tech companies, all of them will have some sort of a question that involves generic 'product sense'. Something along the lines of 'how would you design an alarm clock for the visually impaired?' or 'design a better grocery store experience'. This type of questions is meant to look for structure, user empathy, creativity and understanding of constraints and metrics.

Product sense as a thought exercise has major benefits even if you are not currently looking to interview for a new job: Thinking about designing or improving a product that is out of your comfort zone (my favorite thing is picking random objects around the house) trains your product mind to prioritize and ask critical questions - who is this product for, what does it do for them, what user cohorts are out there, which one is the most beneficial, what are their pain points, can I reach a problem statement for that group, what metrics should I watch for and much more.

There are different frameworks out there you can use to answer product sense questions and the most common is probably the Circles method ² explained in Lewis C. Lin's book 'Decode and conquer'. That being said, I encourage you to look for more - there are plenty of frameworks out there that are worth exploring. As you warm up to product sense and strategy questions you will find adaptations and integrations that make a framework your own.

With enough practice, I got to a point where in about 40 minutes (I like to time myself so I can keep my thinking fast and focused) I can come up with improvements or design for a service or a product on a feasibility spectrum that ranges from practical to a moonshot.

The artifact you'll have in hand after your product sense practice will look pretty similar to the above - prioritized solutions based of a problem statement you defined for a user segment in the context of an existing experience. The next form of advanced training is to pick the MVP you designed and think about key metrics and what would make the most sense to measure as a factor of success.

I often like to look at metrics through the product lifecycle lens of acquisition, activation, engagement, retention, monetization and non-functional requirements (NFRs). Theory-crafting around what metrics would drive my hypothetical products to success and why, was helping me feel comfortable talking about data and more importantly ask data-oriented questions at the right time. It's all about repetition - the more you do something the more it becomes automatic you can focus on the next level of thinking.

product talk

We've spent time building products in our comfort zone and practicing product work for imaginary products outside our comfort zone; zooming out of those two, there's a multiverse of product thinking out there that is unknown to us. Try as we might, we are constrained by our own personality, identity and how we approach problems.

In order to break out of our my thought patterns, and even though I was playing product management solitaire, it's time to play a little bit of hyper-focused multiplayer: Every week, I spend an hour meeting with product managers from all over the world for a casual conversation about what they do and why (and food).

Talking to other product managers, aspiring to seniors, I found different ways people approach problems, how they navigate their own company culture and challenges they are dealing with. It also makes me feel like a lot of the challenges I'm dealing with are shared across organizations and industries which is comforting. But most of all, talking to product managers in a casual environment exposes me to a variety of opinions, cultures and thought processes that are so different than mine and that's awesome. One of my absolute favorite things to do is get curious about people and those meetings literally supercharge me.

If you are interested in hopping on one of my one-on-one product talks here's a link for you.

footnotes