Where am I?

This gist is a living, practical document describing what product management is to me and how I do it. All opinions are mine and are not meant to convey THE truth of doing product, but rather serve as a document I can review on a regular basis to remind myself of things that are important for me. Enjoy it in its current form!

Inspired by the amazing Kathy Korevec who, through her writing, showed me the importance of having a grounding personal philosophy.

Growth stages of thoughts

I am a big fan of the philosophy of digital gardens which treats texts published on the internet as editable works-in-progress, encourages publishing early, and growing your understanding of things with time. Thoughts start as imperfect ideas and are refined, reality-tested, discarded, and changed over time - why not make our publishing reflect this process?

On that note, I use the following convention to signify the maturity stage of the notes here:

Seedling (🌱) for fresh, still fairly raw and rough ideas,
Budding (🌿) for things that have stood the initial test of time, but are still likely to be refined,
Trees (🌲) for ideas that have been stable for a good while and are pretty well-embedded in my thought system.

Product management

What is my job?

(🌱) To help the teams ship the right thing at the right time in the right way. (By Shopify - add source, Lenny's podcast)
(🌿) To create a robust, safe, inspiring and exciting structure for the people who "lay the actual bricks" of the product.
(🌿) To create, clarify or dig into the why, even when the conversation to get there is extremely uncomfortable. Clarity over comfort at all times.
(🌲) To communicate back-and-forth: customers to team, team to management, marketing and sales to team, design to customers, support to management etc. To increase understanding, to surface the invisible work, to create shared context. To create protocols that help different groups understand each other.
(🌲) To facilitate - from idea to plan, from unknown to known, from vague to precise, from hidden to visible, from undecided to decided.
(🌲) To discover, listen to, distill and share our customers' jobs, pains, wishes, dreams, workflows, challenges, quirks, thoughts and opinions that - when addressed - can "delight customers in hard to copy, margin enhancing ways" source.

What is product management?

(🌲) Product management is a connective role and is valuable on its own - no need to feel inadequate because I'm not specialized like a software engineer. Working full-time in product management, at best I'd be a mediocre engineer (or engineering manager), so I try hard not to stick with what feels more familiar or comfortable - or what seems more "valuable/real" to me at the moment. Instead, I'm working to get comfortable with ambiguity and focus on efforts where I can make the biggest difference, on what no one else has time for, and what is truly the essence of my job - things like customer discovery, problem definition, communication, thinking in outcomes, and connecting cross-functionally. On that note, it's very hard to be a good product manager without having sufficient number of connections with other teams and functions across the company.
(🌲) While it is a connective role, product management is a set of skills that can be learned (and a craft that must be honed). Product management is not a personality trait that someone is either born with or not (and can rely on without putting constant, daily effort into improving). For some people it comes more naturally than for others (like everything else), but it's an illusion that natural traits alone are enough to make someone a really good product manager. There's so much nuance in the craft - and so much science in things like brainstorming, customer discovery, storytelling etc.
(🌲) There are many things that are not your (or your team's) fault, but are still your responsibility. There's huge value in recognizing this distinction and pushing for whatever needs to be done. Sometimes your goal is to make it happen - whatever is truly important for your team and your product, even if it means going beyond the usual scope of what you (and your team) are responsible for.
(🌱) To some degree, everything is product - everything that has something that somebody is using that is supposed to solve a problem in some way. While the day-to-day tasks of a PM depending on the context can vary, the "core" is the same - everything we do must provide value to the producers and consumers of that thing in a delightful way. In teams that are more "hidden" from the "customer surface" (like infrastructure teams) the ultimate test for a PM is whether they provide value to the team - my job is to make their job better. I want to be a Readwise Reader they didn't think they need until they tried it.

Product laws of physics (as I see them)

To paraphrase Sam Altman, I shall not try to fight the product equivalent of the laws of physics. Even more importantly, I shall not forget they exist.

(🌲) I need to maintain a clear, available, up-to-date roadmap of items that are happening now, next, and later — all stemming from the product and company strategy.
(🌲) Everything I do must have a very clear reason and value proposition. At any point, I should be able to answer the questions: "What are we doing, why are we doing it, what impact do we expect this to make, and why are we doing it now?"
(🌲) I need to hear from my users (that is, people who use the things I build, who sometimes aren't the actual customers of my company) regularly. This helps both to spot new opportunities and to reality-test my assumptions (which implies that my roadmap items should have these assumptions clearly defined in the first place).
(🌿) I need to have a system for daily temperature checks on my KPIs and important metrics (which implies I need to have them clearly defined in the first place).
(🌿) A huge part of this job is and will always be storytelling (which implies having a valuable, customer-data-backed, not completely made-up—story to tell in the first place). I need to always be able to tell the story and not just report what the team is doing, can do, or has done in the past.
(🌿) Without proper product marketing, even the best work from my team will likely have limited impact. Product marketing, support, sales, and other go-to-market functions must be involved early in the process.

Practical tips of "doing product"

(🌿) It's important to know when to discuss a specific topic with different groups. If I bring a very ambiguous topic to a larger team too early, I'll likely get shallow discussions, chaos, and confusion. Bringing it too late is (obviously) bad too, for several reasons: I might assume something is feasible when it's not (or vice versa), in most cases the team will have valuable insights about the customer experience that I missed, or they might have much better ideas for solutions than I do. As a rule of thumb, it's good to first conduct discovery, test and explore an idea with a "product trio" and stakeholders/clients through a few iterations before bringing it to the entire team. source.
(🌿) When bringing a topic to someone (or a group) for the first time, I aim for simplicity. I remove 50% of sections from the product brief, 50% of goals, 50% of information—50% of whatever I'm presenting. Too much information at once makes it hard to convey the message, distracts and overwhelms the audience, and makes them lose interest.
(🌿) A huge part of this job is transferring knowledge from people's minds and scattered channels into tangible artifacts and maintaining a usable knowledge repository. This includes product briefs, experience maps, research documents, customer quotes, historical context, and those crucial, random bits of information a colleague might share in a Slack channel at 11pm on Saturday that could completely change what your team plans to build. Archaeologist, anthropologist, futurist, archivist, and librarian are just some of the many hats a Product Manager needs to wear.
(🌲) Best solutions and ideas rarely come during carefully-allocated timeslots (like brainstorming sessions or dedicated calendar blocks). Inspiration comes from everywhere and everyone, and can hit people when they least expect it. I try to capture these ideas IMMEDIATELY after they come to my mind—they'll be lifesavers later. I paste them in Miro, record them on my smart watch, write them down in a notebook, or add them as tasks in Todoist. Any medium will do, as long as I don't let the idea fly away.
(🌿) Critical mistakes in the early days can compound extremely quickly. "Design for the future, it'll be here before you know it."
(🌿) Meetings should happen after I did my homework, not before. I try to follow the guidance of Matt LeMay - for every synchronous meeting with your team, I spend ~3x the time I assigned for this meeting on preparation. "Meetings should not be about deciding what the meeting is about".
(🌿) I need to avoid product martyrdom, which is well described in Product Management in Practice.
(🌱) Problem definition and problem resolution should not happen at the same meeting - give the people a room to breathe, think and process the information.
(🌱) The longer-term roadmap must be grounded in real problems - this is what makes it believable, both for me and my team. The way to discover real problems is to conduct research that is specific to my context. Not confident in my roadmap? It often means it needs more grounding. How to do grounding? Research: listen to customer stories, to engineers' pain points, to the experience of the support team, to what the market is doing.
(🌱) I need to regularly go broad and go deep to make meaningful progress. Go broad to get out of my narrow way of thinking what the world can be. Go deep to really get into people's minds as I'm exploring a particular opportunity. (But how to actually do it? Examples?)
(🌱) The meeting before the meeting rule is true not only for "business" meetings. The "meeting" before the meeting isn't always a meeting - rather some form of "warming people up" before the meeting (a Slack message, an informal chat, a good prep material shared with them etc.)
(🌱) Perhaps starting from having the absolute clarity about the high-level goals and moving top-down, discarding everything that doesn't align well is not an absolutely necessary step that need to happen before I can start crafting this now-next-later.
(🌱) "Treat customer requests as input, not instructions" (source)

Personal

How do I work?

(🌲) Simple plan and structure helps me. Unaddressed chaos spirals me into more chaos.
(🌲) Too much irrelevant and pointless information (such as social media news) overwhelms me and brings me absolutely nothing but anxiety. When I stick to one, high quality source at a time, and explore it in depth (get familiar with it, understand it, log it in my knowledge repository, apply it in practice) I learn quickly and I progress fast.
(🌲) Like every human, I need regular periods of proper rest, stepping back and reflecting before diving back into the day-to-day.
(🌿) I feel much better and perform much better when I don't neglect my support structure (sleep, relationships, exercise, diet etc.), even though I sometimes think I'm "too busy" to take care of it.
(🌿) I often use props (like fidget toys) to focus during meetings. I prepare to almost every meeting I have, even a "chill" one.
(🌲) A cliche, but I shall keep reminding myself that being busy is not the same as doing meaningful work.
(🌿) I won't care about something I don't deeply understand. Most likely, other people won't either.

How do I learn?

(🌿) Just like getting serious returns on investments takes time, getting serious returns on learning and experience takes time, patience and 10000s of little, awkward and humbling moments of facing the truth about your current skills. I know it, but I often need to remind myself of it.
(🌿) To fully learn new concepts I need to first understand them, then "marinate" in them, then use them to create something.
(🌲) I'm often surprised by how much I can learn about a scary topic in just 2 hours. I'm usually amazed by how much I can learn in 2 days. But I need to remember that I'm far from being an expert and there's a whole universe of things I don't know I don't know.
(🌿) Consistency > crunch mode, but sometimes the latter is necessary.
(🌱) I won't learn how to swim by reading a book about swimming. I won't know what water feels like if I don't let it touch my skin.

Tools I use

(🌲) I'm using Todoist to capture all tasks the moment they come to mind: commitments I've made to others, things that need my focused attention, my daily to-do lists, etc. Chrome add-on helps tremendously with this. I also use a Slack workflow that reminds me to prepare my daily to-do list.
(🌲) Toggl helps me manage my time and attention. By naming a task, starting the timer, and stopping it when finished, I can maintain focus on one thing at a time. The unexpected benefit: discovering that tasks I've procrastinated on for days often take less than 5 minutes to complete - a revelation that makes similar tasks far less intimidating in the future.
(🌲) My Remarkable is an extension of my hand. I use it daily both for meeting preparation and for capturing thoughts in real-time during discussions.
(🌲) Claude helps me learn various topics quickly. I appreciate having a resource where I can ask even the most basic questions without hesitation (think of the "I don't know what X is and at this point I'm too afraid to ask" meme - well, I'm never afraid to ask Claude). My most frequently used prompt is "Explain X to me like I'm a tech-savvy 18-year-old".
(🌿) I'm fangirling Jira Product Discovery. Seriously, it's awesome.
(🌿) I record and transcribe important meetings so that I can fully focus on the discussion rather than worry about forgetting half of it by the end. This also saves both myself and my teams from having to revisit the same information later.
(🌿) My ADHD diagnosis made a world of difference in how I work, plan and think of myself. I'm no longer ashamed of the props and accommodations that help me do my job well.

Random bits of wisdom

(🌿) There's only one place in the world where success comes before work - it's the dictionary.
(🌿) One way to avoid accountability and having to make a decision that will affect the real world is hiding behind ambiguity, slogans, evergreen truths, surface-level, general language and terminology. That being said...
(🌿) Lack of decision is a decision. What's not said says something too. Also, the lack of a clear answer is an answer. Not getting the answer I wished for doesn't justify not doing my job.
(🌿) Self-awareness alone is not enough to do my job well. I can be self-aware and know that I'm not competent in certain areas, but this is not an excuse for not doing my job.
(🌿) Pessimism is contagious - I can both get infected and become a spreader.
(🌿) To quote Steve Jobs, the doers are the major thinkers - the people that create major change in the industry are the ones that are both thinking and doing (which, in the context of IT, means building software). Steve Jobs was not a programmer, a designer, nor an engineer himself, but he knew how to "translate into business" the potential and creativity of ideas coming from the "thinkers-doers" crowd.
(🌿) I'm trying to make myself do the hard things. What's even harder is teaching myself to stop doing things I feel tempted to do or do on autopilot.
(🌱) The greatest failing of many leaders lies not in their actions, but in their inaction.
(🌱) I think it makes sense to only involve the team in high-level discussions (such as identifying opportunities) after I've thoroughly researched the current situation and materials on the topic that already exist. This means understanding existing opportunities in the backlog, previously documented team ideas, and other relevant ground-level details. Without proper research first, I'm basically asking the team to do my job for me. It's okay to ask them for places (and people) to look at - not okay to expect them to serve a clear description of some topic, wrapped in a pink ribbon. Additionally, asking the team to explain a broad topic to me from 0 when pre-work exists and they already spent hours preparing it in the past is simply disrescpectful.
(🌱) It's always okay to ask questions about technical details and why we're doing things a certain way. It's not okay to be strongly opinionated without having proper technical knowledge and experience.
(🌱) With people comes complexity. The more people, the bigger the complexity.
(🌱) Excellence is pain tolerance disguised as genius.
(🌲) Shit happens and will happen - it's all about how I respond to it.
(🌱) "How can we make it a work of art?"
(🌱) When I talk to engineers about product terminology out-of-context, they feel like how I feel when they talk to me about technology out-of-context.
(🌱) "He was lucky, but more often than not he made his luck" (Extreme Ownership). "Luck is manufactured by being 1% better every day" (source)
(🌱) Repeated, regular, long-term exposure is a key to all learning, sense-building and mastery
(🌱) Empathy building is required to actually understand and start caring about something
(🌱) "Statistical user" does not exist.
(🌱) There might be no stupid questions, but asking a good, valuable question requires decent prep first. The value of an answer from a "cold" vs "warm" question is drastically different.

What are your thoughts?

What do you think of my product philosophy? What's yours? If you want to chat, drop a comment here or send me a DM!

Liked the content? Don't forget to star this gist!

borsos-ilo/product.md