I have some issues with the concept of “automating” or “scaling” product management, which I went into in this blog post — what I haven’t written up is what I do use.

This is the process for directly running a product or multiple products; leading a team that runs products has a different set of tools required which I’ll go into some other time.

It’s pretty old school! I use whatever is available for shared documents,  [Confluence|Wiki|Google docs], to keep a freeform record of customer contacts. During a meeting I take notes on my phone (Apple Notes) or my laptop (BBEdit), depending on the need to avoid keyboard noise.

ASAP after the meeting I rewrite them into the shared doc and share the rewritten result with interested Slack teams. I’ve also tried SFDC call notes and direct to JIRA, but found it impossible to correlate and review across customers and projects.

The first raw notes document is a mess of shorthand, repetitions, action items and factoids for me, and acronyms that may only make sense to me. The second is still just notes, but more readable by other team members. This is the citations bibliography for everything else.

I might use it for competitive research as well, or I might put competitive notes in a separate document if they get too big. I‘ll also break the customer notes doc off into new docs every X pages or Y months, which can be useful for seeing changes in the market requirements.

I regularly re-read those notes and research items, looking for common threads, opportunities, and leverage points. I start copying these into a summary at the top of the shared notes document, and I use them to produce more structured requirements docs.

I need a Market Requirements Document (MRD): What is the problem, what industries are affected, how much money is available, what are the titles and responsibilities of the Champions, Gatekeepers, and Buyers?

I need a Product Requirements Document (PRD): What would we build for that market? What features would it need, and who would those features serve? I usually write up enough high level features for two or three major releases before I start trying to decide what might get done.

For a small project I‘ll combine the MRD and PRD. The PRD will be used to produce JIRA epics and stories. This means rewriting and converting from tool to tool, which means doing the creative work of refining, sifting, correlating, synthesizing, and sorting ideas.

The development team is introduced to these drafts as well, and we start to refine them together. Whiteboards, wireframes, and flowcharts start happening here. Maybe some prototype code.

I rewrite the epics and stories of the PRD in greater detail every time I touch them. I also clone them, move them from story to epic, throw them away and start over. Tickets are free, roadmaps are predictive estimates, and the backlog is a playground.

Change tracking, prioritization, progress reporting, workload sizing, and release estimation are driven from JIRA data, often processed in Splunk or Excel for presentation in [PowerPoint|Keynote].

Idea accountability and closing the loop with customers is not tracked in JIRA. That’s my responsibility to take care of, which I do by reviewing the customer notes document whenever I have contact with the customer or their sales team.

The system I suggest requires a lot of work. The PM must open themselves to as many sources of input as possible and work to reduce the firehose to sensible, high-leverage ideas for engineering to implement.

Centralization is critical so that the PM’s work is visible and can be taken over by another PM. Some sort of tool helps, but the specific tool chosen doesn’t matter as long as it doesn’t get in the way. The more workflow a tool suggests, the more it’s going to get in the way.

Moving ideas from tool to tool at each stage is actually very helpful. Putting a technical barrier between input and output that requires human brainpower to push things through is analogous to transcribing from longhand notes to an essay in a text editor.

People are excellent at doing all sorts of creative work, but they’re also excellent at avoiding work and justifying results. Getting work done requires forming useful habits, and critically rewriting your own work is one of those.

There are a number of complaints that come up with this conversation, which I synthesize to “that process can’t scale!” As I understand the argument: “As a PM I want to offload portions of the workflow to an automatic system or a process that other teams do so that I can do more”.

Or the more pernicious: “As a PM I want to point other people at automated systems so that they don’t have to interact with me to get what they want”. As an introvert, I do sympathize with this position, but not very much, so let’s drop that one.

The work of doing product management is not automation friendly. Software is eating the world, and as product managers we are the chefs preparing that meal. It’s only natural to look at our own job, see a process and think “that can be automated too!”

It’s not true though, because software can only eat the things that are expressed in numbers without losing context. The computer can’t understand context. People have to do it, so the product opportunity is in personal productivity tools, not team aids.

Handling scale as a PM means managing the number and scope of projects, changing the balance of anecdata and metrics, and avoiding all the easy work that blocks this process with a false feeling of accomplishment.