Skip to content

Latest commit

 

History

History
75 lines (45 loc) · 7.92 KB

how-to-benjamin.md

File metadata and controls

75 lines (45 loc) · 7.92 KB

How to Benjamin

Hi there, I’m Benjamin 👨‍💻 this is a working ‘readme’ on how I operate, and what you can expect from me. It is loosely based on How to Rands and other concepts of a personal doc.

This is a living, breathing document—and like me, always subject to change :)

Intro 👋

I use the pronouns he/him and am based in Hyde Park, Chicago, Illinois, United States. Before product management, I spent time in marketing, business operations, and training roles. Teach me something new!

I bias toward written communication (1-pagers, etc) as it gives me something to which I can respond; but am happy to jump on a call or to spitball and brainstorm.

North Star principles ⭐️

🥇 Prioritize what matters. I believe you need to take care of yourself first, your family next, and then you can take care of everything else (which includes work). When thinking about work, I prefer clarity and focus: What problem are we solving? and understanding why we decided upon a given bet.

⚙️ Think in systems. Not everything needs to scale, nor be long-lasting. I like breaking things down to understand how each bit fits and works together; and what tradeoffs we’re making, by designing something in a particular manner. I probably bias toward being verbose and possibly exposing too much functionality/‘work’ on clients or customers. But if we talk about the system and how this product piece fits within the whole, I hope we come up with the right-sized solution for where we are today.

🤓 Ask lots of questions. I love asking questions! Even if I suspect I know why something is a certain way, I find that asking questions can elicit different context. Often times, I learn something new—and that helps change my own perspective! I’d rather you over-communicate and ask more questions, so we can do our best to understand one-another’s positions.

💡 Simplify. And then simplify it again. I believe this is some of the hardest work, but when you get it right, it’s ✨ magical ✨

💛 Be kind. We won’t always agree on everything. That’s good! But when facing disagreements, I strongly prefer that we respectfully and kindly explore our positions. Help me understand where you’re coming from! I believe that building great products happens best when we’re operating as a strong team. As humans, we have distractions, emotions; we have both bad and good days; we have a world beyond work. Just remember that we’re all people living our own lives, and trying to do good work.

🏃‍♂️ Bias toward action.

Frameworks

As a product manager, I lean on a few approaches depending on the context:

  1. 🚀 Kano model for early-stage work.
  2. 📄 RICE for more established work.
  3. 🔙 Working backwards is helpful as a what must be true? when exploring a long-term vision, or a specific, targeted commitment. I especially like this when thinking about specific dates; and lean on a work back schedule, taken from my experiences when producing live events.
  4. 🧳 Jobs To Be Done.
  5. 📋 I like working with clear agreements on how we make decisions. Previously, I’ve enjoyed both the RAPID and the RACI approaches; more important than a singular approach is that we agree on how and when we use these.

Words

Now in glossary.md.

Feedback

I’m here to learn, and to get better at my craft! 🚀

The best—and sometimes hardest—part of product management imho is adapting to the project/team/environment, as every organization is different (and constantly changing). Every perspective is valid, and I’m 🙏 grateful for you trusting me to grow, and to get better.

I find it most helpful for you to let me know feedback in real-time, and include specifics on what or how I can improve. (The Situation/Behavior/Impact framework resonates with me!) Drop me a brief message, and I will try to course-correct in-the-moment. If a synchronous chat might be helpful, send me a message and we can find some time to talk! Or, just throw time on my calendar - it should be up-to-date, and in the worst case I will decline or request that we move to another available moment.

Meetings

People often say meetings are bad. I…might disagree? Meetings are another tool, and we’re all different humans trying to do big things, together.

That said, I think of meetings in a few different contexts:

  • 🔁 Recurring sync: Team meetings, standups, stakeholder review sessions, etc. These should have notes with any action-items, and should be scheduled at a regular cadence (eg. bi-weekly). Open to anyone interested.
  • 🔂 1x1: Same as previously, except between two humans. More informal, but I still believe in shared agendas/notes.
  • 🛑 Decision moment: Do we need to align on a direction and/or make some decisions? Ideally, a pre-read (such as a 1-pager) has been shared. Also helpful: Is this a one-way or a two-way door?
  • 💡 Brainstorming: Can we get together and talk about opportunities and what might be possible? Probably not useful too frequently, but these can be great for creative thinking (more fun with 👯‍♀️ friends)!

If you want ✨ bonus points✨ please schedule any recurring meetings on a Tuesday, Wednesday or Thursday. If we have a 🏖️ long weekend (or if I’m taking a long weekend myself) I’d love not needing to re-schedule everything from a Friday or a Monday…

Templates

  • 1-pager: Simplified Template [Google Doc]: This is a product or proposal template. What are we thinking of doing, why do we care? This is a simplified template, and is good for general product work.
    • 1-pager [Google Doc]: This is a more robust 1-pager template. It attempts to describe some use cases, and may be better-framed for going from zero-to-one on a product feature.
    • prd [Google Doc]: This is a product template, specifically a product requirements document. It might be too detailed for some work, but is intended to give much more exhaustive clarity than a 1-pager. I find this useful for greenfield or exploratory work - let’s explore at topic or domain together!
  • sbar: This is to help facilitate a key or critical decision, and is intended to help document the decision-making process so others can quickly and easily understand what we need to decide (the “situation”) with relevant/factual details (the “background”) and some commentary (the “assessment”) leading to a proposal (the “recommendation”).
  • retrospective [Google Doc]: For team retrospectives, so we can get better!
  • 1x1 [Google Doc]: For recurring syncs, so we can stay aligned!

Etc

I use my 💻 computing devices as my ‘external brain’ and rely upon my calendar, notes and reminders. I generally try to share what I have, and/or to work in public. Feel free to ask if you want me to publish my notes, or to elaborate on anything.

I like ☕️ coffee.