Category: development

I’ve played product manager more often this year than I have in years. It’s been a fun role to get back into.

It’s also been a long time since I played product manager at a larger company. The last two times were tiny startups, and well, it’s a very different experience.

With tiny startup product management, I didn’t have a lot of internal expertise to rely on, so most of the research was external – I had to find people to talk to, find research, do a lot of research, and figure out how to validate assumptions.

A lot of that is similar in a larger company, but, the expertise is inside the walls at a larger company. I’ve had great results in all of my recent projects by just asking for folks who have expertise in big public Slack channels and they just appeared!

I think we frequently discount our own, and our peers’, expertise when doing discovery and research, especially our peers in customer support roles. I think that’s a huge mistake. Who talks to your customer more than the folks in customer support? Nobody. Who knows your product better than the people who have to support it? Pretty much nobody.

I was able to jump start onboarding to new subject areas a whole lot faster by asking our support teams about their processes and doing user interviews, just like I would with a potential customer, and that lead to some really interesting discoveries and avenues to explore.

So, don’t take your internal experts for granted! Ask them things! Praise them! Share your results back with them!

I mentioned this last week, but while I’ve been fixing formatting issues on my old blog posts, I’ve made the mistake of reading some of them. Getting a glimpse of me 20 years ago has been interesting – he was so angry, usually about work, and talked about it a lot.

That guy was on the verge of burnout every other week, and I think he was actually burned out quite a lot.

I’m not angry about work anymore. I was last really burned out over five years ago.

I think if I’d kept going the way I was headed back then, I’d be a cynical burned out husk. I haven’t read beyond the beginning of 2003 yet, but I can’t wait to see when the switch flipped (having a “coming attractions” for my own past is pretty weird).

If you asked me right now how I avoid being a cynical husk, I think it comes down to my rules for working:

• Never miss a chance to celebrate. We’re confronted with failure so often at work, that we should celebrate every little win.
• Focus on the who and the how. We don’t control what we work on most of the time, and pinning our self-worth to the success or failure of the things we work on is a recipe for sadness. So, I no longer really care what I work on. I care about enjoying the people I work with, and focus on how I work. I can control how I work more than I can any other part of it.
• Compete only with yourself. I try not to compare myself to other people. I’ve got my challenges and other commitments, and I know nothing of theirs. So, I only compete against Past Me™️ – which also helps make sure I’m constantly improving, even if it’s just a little bit.

That’s not a lot of rules… but they work for me. I might change them…

I have a bad habit at work of saying “I don’t care” without qualifying it. It comes off as sarcastic or dismissive, when that’s not how I mean it – which means I need to find a new way to express it.

Most of the time, it pops out of my mouth when my manager asks me if I want to work on something and then she gives me a look, and I have to explain myself.

Here’s the explanation: I no longer care what I work on. I’ve built one of pretty much anything I’d ever want to build, and the what just no longer matters. What matters to me is how I work, and who I work with. I alluded to this in the post about ficlets, but the individual projects blur together. The thing I remember is the thrill of building something with people. I remember the people, and how I felt while we were building whatever it was.

I still believe in constant incremental improvement, and only competing with myself. I also now finally understand that just building something that’s technically superior doesn’t guarantee success. Success or failure in the eyes of the market almost never has much to do with the code that implements it. It requires the work of everyone on the team, every discipline, and a ton of luck.

And all of that means I’d much rather focus on making sure that I’m helping everyone else on the team do their best work, and asking them to help me make sure I’m doing mine. That’s literally all that matters to me at this point. Yes, I love big meaty technical problems, but that’s a very small part of the overall solution. The most important part is the borders where disciplines meet and making sure that those borders are seamless, complementary and supportive of the rest of the disciplines involved. That’s way more complicated, and way more rewarding when it works.