Good remote PM/Bad remote PM
Ben Horowitz’s 1997 post Good Product Manager/Bad Product Manager is still the best summary of the PM role I’ve seen. When I’m asked by someone outside tech what a PM does, I usually say we’re responsible for building the right product at the right time. Many of the qualities he talks about are especially critical for a remote PM, and being remote can actually amplify them.
Context Gathering
A good product manager knows the context going in (the company, our revenue funding, competition, etc.)
Being remote forces you to systematize your context gathering. In an office you can often rely on irregular 1:1s and hallway run-ins. Good remote PMs know their key counterparts across teams, and communicate with them on a regular cadence. They have systems to regularly gather info on customers and competition firsthand, vs. relying third party research or reports from their coworkers. They help their team see around corners.
Foresight
Good product managers don’t get all of their time sucked up by the various organizations that must work together to deliver right product right time … Bad product managers put out fires all day.
Being remote actually makes this one easier. Good remote PMs use crisp, early communication to stay in touch with other functions (design, marketing, data science). They are not the team gopher. In an office, a bad PM can cover up lax communication by swinging by a teammate’s desk to work out a last minute change due to lack of foresight. A remote PM can’t rely on this safety valve.
Crisp written communication
Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what” … Good product managers create leverageable collateral, FAQs, presentations, white papers … Good product managers take written positions on important issues … Good product managers err on the side of clarity vs. explaining the obvious.
Written communication is a critical part of being a good PM. Most PMs will agree and pay lip service to this principle, but if you look carefully many do not in fact spend much time writing out goals, strategies, good product specs, documentation, or FAQs. In an office this can be concealed by informal chats and periodic presentations. A good remote PM lives and dies by their written communication and documentation.
Iteration
Good product managers decompose problems. Bad product managers combine all problems into one.
Breaking down problems into bite-sized pieces is especially critical for remote PMs. Product specs should reflect this, and either have clear sections for each version, or be broken out into separate docs entirely. This, combined with a regular cadence of check-ins with engineering, is the only way to make sure the end product you see isn’t a complete surprise to you.
Discipline
Good product managers send their status reports in on time every week, because they are disciplined. Bad product managers forget to send in their status reports on time, because they don’t value discipline.
Discipline is critical to success in any remote job. Just like making your bed every morning is easy to skip, letting your weekly status report slip, or your 1:1s, or writing a spec for every feature however small, seem innocuous. But a good remote PM knows that diligently sticking to these principles is the only way to leverage themselves from afar. Building up a canon of context and material that can be referenced asynchronously will enable their teammates to function autonomously, make their own decisions, and move faster.
Original 1997 article - I encourage a re-read, it’s only 650 words (2-3 minutes).