Posts tagged “product management”

30 June 2025

Some Products Just Aren’t Big Companies

This take on the Pocket shutdown resonates with me real hard:

“What began as a read-it-later app”, they assert, “evolved into something much bigger.” That was the whole problem: the mistake that led ultimately to this “difficult decision” by Mozilla. Pocket was a good tool. Its integration with Kobo, another excellent tool, made it that much more valuable to users like me. We didn’t need “something much bigger”. But by trying to turn Pocket into something much bigger, Mozilla actually killed it.

I feel like nothing has changed since I wrote about this kind of thing in… 2012:

This is the core of the disappointment that many of us feel with the Sparrow acquisition. It’s not about the $15 or less we spent on the apps. It’s not about the team’s well-deserved payout. It’s about the loss of faith in a philosophy that we thought was a sustainable way to ensure a healthy future for independent software development, where most innovation happens.

→ Some Products Just Aren’t Big Companies

30 June 2025

New advice for aspiring managers

Great advice here for new managers in this wild time we find ourselves in. In general:

Whereas the previous focus of managers was to rapidly hire and scale their teams, today’s focus is on expanding impact. This is because in today’s macroeconomic environment, output is key. In the eyes of a 2025 company, the more that you can do with fewer people, the better. There are very few additional people to go around, so the focus is on how you can help your team do more with less.

James focuses specifically on EMs, but the advice definitely applies to PMs too, so check out his post if this is you!

→ New advice for aspiring managers

28 June 2025

On estimates as navigation, not promises

I’ve been thinking about engineering estimates a lot and need to write about it. But for now, Adam Keys sums it up nicely:

Everyone knows surprises will happen. The estimate should help the team make better decisions when they do, not box them into promises they can’t keep. The best estimates I’ve given weren’t the most accurate—they were the ones that helped teams navigate uncertainty instead of pretending it away.

→ On estimates as navigation, not promises

22 June 2025

Product Management: The Good, the Hard, and How to Know If It's Right for You

An engineer recently sent me some questions about the Product Management role. I took a long time to respond because I saw it as a great opportunity to reflect on the role and what it means to me. I decided to share my answers below, in case it’s useful for anyone else!

What did you like the most about your job as a PM? (I say past tense because Director can be different)

The joy of shipping, and shepherding products and features from ideas all the way through execution and user feedback and continuous iteration.

To me, the PM role is a people job. How do we get people to work together to do amazing work? How do we get the best ideas out, how do we make them real? How do we build things that people genuinely enjoy using, and don’t mind paying for? How can we understand how our products make people feel, and how can we make that better?

If you’re able to get into a product loop that does that over and over, it’s the best job in the world. You get to understand complex user, business, and technical needs, make sense of it all, and support a team of people to get useful products into the world. And then you get to talk to the people who use those products about how to make them even better.

Daniel Pink says we are all motivated by 3 things: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). At the best of times, I can’t think of another job that combines those 3 things as thoroughly as Product Management does.

What is the one aspect of the role that makes you from time to time (but consistently) say “I don’t think I want to do this any longer”? Or “I need a break from this”?

When we get caught up in the human tendency to forget about what we’re trying to do (that purpose from the previous question), and focus on our own needs instead. When I interact with teams and people who find their identity in their work to such an extent that it overshadows how cool it is that we get to do this stuff together. In short: when internal politics take over.

I don’t resent this tendency any more, to be honest. I used to, but not any more. This is normal human behavior—I am not immune to it, no one is. We want to feel heard, we want to feel useful, we want to be seen as competent and smart. But I now recognize very quickly when a discussion about a project or a product becomes about self-preservation vs. what is best for the team and the product and its users, and I am allergic to it. It makes everything more stressful. It requires having to “read between the lines” every minute of the day. It slows everything down. It makes everyone grumpy and wary of each other. It is poison to healthy teams and products, and it affects me deeply (too much).

I deal with it by losing myself in side projects, and spending deliberate time with the work people who don’t succumb to that behavior.

How do you advise me if I were considering either an EM or PM role to decide on which is more suitable to try out first?

I think the best starting point is to reflect on where you naturally find energy, especially when things get hard. Do you find satisfaction in crafting elegant systems and seeing the architecture click into place? Or do you come alive when you hear someone articulate a pain point and you can immediately imagine a better experience? Do you find yourself trying to optimize team throughput and code quality, or do you have an interest in clarifying ambiguity, getting people to work together happily and effectively, and shaping decisions through influence rather than control?

PMs and EMs both lead, but in different ways. Engineering Managers lead through technical insight, mentorship, and a responsibility for the velocity, health, and growth of the team. Their scope is often constrained by the product strategy/roadmap and what’s possible technically, and their main outcome is helping the team build the right thing in the right way.

Product Managers lead through context, clarity, and storytelling. They untangle complex ambiguity, and they create clarity when everyone sees the world differently (which happens on every project…). Their main outcomes are making sense out of too many chaotic inputs, aligning everyone on the problem to be solved (and how to solve it), and keeping the team connected to each other and customers.

15 March 2025

"Ack, think, act"—building trust as a product manager

Many (oh my word, so many) years ago I wrote that I thought “fairness” is the most important characteristic of a good Product Manager. I still stand by that, but I had another thought recently about a related characteristic that forms the other side of that coin.

Jakob Nielsen’s 30+ year old usability heuristics remain true to this day, but it’s not just relevant to UI/UX. In particularly I think “Visibility of System Status” is one of the most important skills a PM can internalize. The principles states:

The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.

When users know the current system status, they learn the outcome of their prior interactions and determine next steps. Predictable interactions create trust in the product as well as the brand.

A PM can do nothing without trust. And to build trust in an organization, applying “visibility of system status” thinking is the #1 way to gain (and keep) that trust. That means a PM needs to:

Ack: Acknowledge comments or questions as soon as reasonably possible (within hours, not days), even if it’s just to say, “I saw this and will get back to you.”
Think: Respond to the original comment/question—with ultimate clarity—in a timeframe that balances thoughtfulness and pragmatism (days, not weeks).
Act: Follow through on any commitments / next steps with regular proactive updates (for as long as it takes).

Note that the order is important here as well. Don’t Ack only after you’ve taken the time to Think. Don’t Act before you Think. That seems obvious, but I’m sure we recognize the wrong order all around us (and in ourselves!) all the time.

This all might sound hard, but once you’re in the rhythm of this cycle, it becomes second nature. “Ack, think, act” becomes just the way you go through your day. I think this is something we should all aspire to more in product (and probably beyond).

2 March 2025

Social Development, Self-Development, and What Work Is For

I agree with Elle Griffin that Social Development > Self-Development:

This might sound obvious, but I think we live in an era of “secure your own oxygen mask before helping others,” and while that might be a helpful mantra for airplanes I think many of us don’t seem to recognize when we are already wearing oxygen masks. We don’t need to keep adding even more oxygen to ourselves, we need to start directing our attention to others. We need to focus less on self-development and more on social development.

Elle goes into wonderful detail about what this means at a practical level—highly recommended post. Also worth noting no one is saying self-development is bad. It should just be a balance:

Those who participate in self-development and self-care in a healthy way, and for the benefit of themselves and their communities, are not the subject of this essay. But in excess, self-development can create a world of self-interested individuals and that’s what I’m up against here. I’m against the continual process of self-betterment at the expense of community-betterment. I’m against participating in too much theory and not enough action. We can focus on being more loving and more empathetic and more compassionate all we like but we won’t actually be any of those things unless we do something to help our families, our close communities, and even the world at large.

I thought about that piece as I was reading Mandy Brown’s What is your work now?

When talking to people about their work, one question I often ask is, “what is your work now?” Not what is your job or career, but what is your work. Jobs and careers are, at best, the means by which we get our work done while also keeping a roof over our heads; but our work is always bigger than that. Our work is not only what we deliver for a boss or an organization, not only the metrics we’re unjustly measured on or the revenue targets we’re held to, but all the change we make in the world, all the ways we we use our unique gifts to contribute to a living world, to our own liberation and to the liberation of every living being around us. This is the work that rarely shows up on a job description but we can never let go of, the work we yearn for even when we’re tired, the work we grieve when we’re cleaved from it.

The key here being, “all the ways we use our unique gifts to contribute to a living world, to our own liberation and to the liberation of every living being around us.” It feels like this is a good time to think about what our jobs are for. What do we work for?

I know that for me, my job is about shipping value to customers, but for the last few years my work has been to show engineers what good product management looks like, and that we can move mountains if we partner together well. Suddenly that feels like too low of a bar though, so… time to revisit!

8 February 2025

You're missing your near misses

I like this idea from Lorin Hochstein about focusing more on the almost-incidents in our products:

Because most of our incidents are novel, and because near misses are a source of insight about novel future incidents, if we are serious about wanting to improve reliability, we should be treating our near misses as first-class entities, the way we do with incidents.

I imagine that a culture of “post near-incident reviews” could be really beneficial for the resiliency of our products—and our ability to predict and avoid some of the really catastrophic incidents.

20 January 2025

What to do about time goblins

Once we’ve got a plan and that plan is locked we’re in this rare and special place where the things that will pull us off-course haven’t happened yet.

— Raw Signal Group, What to do about time goblins

20 January 2025

Managing Up

Michael Lopp has a great post about “managing up”, including how problematic that term is:

To me, “Managing Up” has that “your boss’s job is more important than yours” feel, which pisses me off. Your boss’s job isn’t more important than yours; it’s different.

He goes on to share some great advice for what to share with your manager, and when. For instance, when to share something immediately:

Unexpected developments. A situation appears in front of you, a non-threatening one but unexpected. Strange. Something is up, but you can’t discern the backstory story or the intent. It is unfamiliar. Tell your manager. Now. Just a brief note. A heads up. It’s probably nothing—it usually is—but there is a chance your manager’s context plus your suspicions equals additional clarity.

10 January 2025

Regarding "missed" and "slipped" deadlines

I really like Basecamp’s concept of “Hill Charts”. The gist of it is that each project we work on has two distinct phases: a “figuring it out” phase and a “making it happen” phase:

To quote from their post about it:

First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns.

Eventually you reach a point where there aren’t any more unsolved problems. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.

“Figuring it out” is full of uncertainty, unknowns, and problem solving. “Making it happen” is all about certainty, confidence, and execution.

I bring this up because one of the issues with quarterly planning cycles and committing to due dates on that cadence is that teams are often asked to commit to dates during the “figuring it out” phase. There’s a lot of uncertainty and unknowns, so teams have to make best guesses. The problem with this is that these do not reflect what Cagan calls “high-integrity commitments”:

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know if we can actually deliver on this obligation, and even more important, if what we deliver will actually solve the problem for the customer.

So what inevitably happens is that, for a lot of projects, the date that teams provided “slips”. I believe this language matters, and I think by framing it this way an org tells teams they did something wrong. But the irony is that in the majority of cases, if teams move a date after they reached the “top of the hill”, they are doing the right thing for the business. They are saying that they have now figured out all the unknowns and uncertainties, and they are ready to make a high-integrity commitment. Again, here is Cagan:

So the compromise is simple. The product team asks for a little time to do product discovery before commitments are made, and then after enough product discovery is done to consider the risks, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.

I think it’s important to encourage behavior that does the right thing for customers and the business. The right thing would not be to try to cut corners to meet a date that was committed to during a “figuring things out” phase. I also don’t believe the right thing is to inherently communicate to teams that moving a date once they reach the top of the hill means they “missed” a commitment.

I think we should be very clear about the nature of commitments when we make them. What is our confidence in our dates? Are we still figuring things out? Or are we at the top of the hill and ready to make a high-integrity commitment? The health of any Product org can be improved if we say that it’s ok to communicate what we think we can accomplish early on in the quarter, and move to high-integrity commitments once teams reach the top of each project’s hill.