what a developer learns as a product manager
As a developer managing a product for the first time, I’m learning a lot about the mental baggage a programmer brings to the product process. What have I learned?
###1 - When starting out, don’t waste time getting caught down in implementation details. As an engineer beginning a product planning process, it’s a reflex. When thinking about a feature, I immediately begin thinking about how it’s going to be built. Begin high-level when starting a product process, or else you’re both getting caught in the weeds and biasing yourself towards the needs of developers.
###2 - Have strong opinions, loosely held.
Developers frequently have strong opinions, strongly held–with experience, we realize that there are a set of best practices for most technical problems, and we need to be conservative about concessions we make in order to protect our time and sanity.
But this attitude doesn’t always work for the product planning process, which involves a heavy amount of consensus building. It’s still important to generate hypotheses about what features a product needs, and be ready to begin with an opinion during meetings, but be ready to modify them to accommodate new concerns and new information.
###3 - Develop systems of keeping track of stakeholder and user concerns. In tackling a feature, developers really only need to think about optimizing two things: time and code quality.
Product managers need to juggle many, many more concerns when executing a new feature, among them: how will business development sell this feature? How will this impact our users, and in what way? How does this affect our brand? And of course, how will this use developer bandwidth?
As a developer tackling product management, my process is shifting from one that only requires implementation decisions (how should I code this) and two inputs (time, product specifications) to one that has many, many decision points and just as many inputs.
As a product manager, it’s important to keep really close track of the insights you get from talking to stakeholders, and to continually evaluate relative importance. For me, notetaking is key–my external brain is Evernote, but I have friends who use a directory of markdown files on Dropbox, or other non-proprietary options. Take copious notes, and after each new information-gathering step, write out how important that information is.
At DoSomething.org, our product process begins with two documents: a product brief, or a high-level overview of the product being developed, and a faceted feature analysis (FFA), or a spreadsheet outlining features in detail. On the FFA, representatives from product, business development, and tech rate each feature for its value to the user, business value, and engineering difficulty, respectively.
Luke Patton, Mike Fantini, and Nancy Lublin inspired this post. Thanks, y’all!