My blueprint

In software product management, a lot of what we do every day is define what we're building, why we're building it, and then how it should be built -- making important tradeoffs along the way. We also deal in mind bending levels of abstraction; what we experience as a user interface sits on code, which runs instructions, which run on circuits made of transistors, which rely on electrons moving through silicon, which comes from sand. To abstract my work into what, why, and how - I've put together this blueprint. Hopefully it helps you understand me and, more importantly, it serves as a guide for myself as I navigate the world of electrons and sand.

What I am working on

Modern companies - with their limited liability shareholder structures - are one of the best human inventions to date. The idea we can collectively organize to provide goods and services to other humans in a way that incentivizes risk taking and bold solutions to seemingly intractable problems is remarkable. To that end, I love assembling teams and getting into the seemingly disinteresting details to come up with those lightbulb moments that lead to a packaged product that truly solves a need in someone's life.

I tend to want to work on challenges that are on the periphery of the spotlight, somewhere deep in the stack, but having a sliver of relevance I think is being overlooked. This led me to spend years working on small details in content management systems, ultimately building features that undergird millions of online stores today.

Put simply, I work on things that interest me, and everything can be interesting if you look close enough.

Why I'm working on it

I got into working with sand and electrons after coming of age in the era of annual Apple keynote events. Time and again the team in Cupertino introduced a packaged product that was immediately and obviously useful, solving problems I could relate to, and in a package that felt crafted in a way the best products always do. I wanted to work on that, and I just didn't quite know what that was.

In college, I took some time to figure this out; interning at a bunch of firms and trying out roles in accounting, finance, IT operations, and ultimately product management. I got two undergrad degrees at two different schools because I didn't quite know where I fit. I knew I loved economics, and despite never being naturally gifted at programming, always had a fascination with the details of how something was built. Ultimately I landed in product - the perfect blend of engineering details and economic tradeoffs.

How I work

I love the work, and really don't enjoy things that detract from what we're building. I work a lot, and want everyone I'm working alongside to be equally as bought in. That being said, I tell folks on my teams to mute me on communication channels; you don't have to respond to me when I send you some crazy idea at 1am, it's just me being excited and I will still be excited tomorrow.

In general, a few guidelines:

Write things down, be succinct, and get to the key tradeoffs. I write a lot of docs because they help me organize my own thinking; I would encourage you to do the same. Send me a doc on something and we'll be able to quickly get to the difficult decisions at hand.
Presentation slides made sense in the 1990s, but don't make sense now. Write your ideas down in long form, synthesize it into something short form, and share in text, audio, or video format with demos of code, UI, or at least some diagrams. Slides force us to think about problems in pictures and bullet points; good for financial reports and bad for building great products.
Remote work is very different than in person. I don't recommend it for everyone. In order to thrive on a remote team you have to be incredibly self motivated and enjoy long hours working on problems solo.
To point 3, meetings are actually very important for a thriving remote environment. Meetings, though, need to be structured differently than the traditional corporate settings we see in movies. They need to be cameras-on, full engagement, working sessions. What are we stuck on, why are we stuck on it, how can we move forward? Meetings to talk about the next meeting agenda are the antithesis of this, don't book those please.
It's really not that serious. It's okay to laugh and have fun when working on tricky problems. I say this for myself as well - I often get hung up on all the work ahead, all the challenges to solve, and forget that consciousness is precious and it's okay to take a step back and laugh at the absurdity of it all. As one of my first leads told me early in my career "it's almost always not life and death, we're not doing brain surgery here".

If you're into Enneagram stuff, I'm an 8. A challenger; assertive, and loyal. Kinda resonates?

And finally, I'm not a big social media person, if you want to chat send me an email matthew.koenig@acm.org

A few of my favorite things: