Seven Things Product Managers Can Learn From Hamilton The Musical

*Many thanks to Colby Gergen who came up with a bunch of these in reply.

(Back-in-the-day-at-the-Public Photo by Joan Marcus for thebroadwayblog.com)

1. Talk less, smile more: Presenting your roadmap to stakeholders
Sometimes it’s best to leave the painfully intricate details of implementation, documentation, and configuration out of your roadmap, and certainly to leave them out of presentations to busy VPs-or-higher with a limited attention span for the how of your product. They most likely want to know the what and the when, with a focus on whether the what meets their expectations. Make sure your communication with them includes the key point : “We’re going to assume state debts” without getting into the weeds about how you’re going to go about collecting federal taxes from Virginians. (I hope you have “Whiskey Rebellion in Western Pennsylvania” listed under Risks btw.)

Bust by Jacques Jouvenal of Aaron Burr chilling in the U.S. Senate. (Unrelated: This is a crop, of the jpg I found on a website, of a photograph, of a sculpture, that was made from an oil painting probably, and that’s a lot of generations.)

2. Who lives, who dies, who tells your (product) story*
If you’re building something worth building, everyone is going to want to leave their mark. Collaboration is great (see: Right Hand Man), but be sure to reiterate the problem you’re solving and why you’re solving it, with common language and themes. Keep repeating it. Honestly, bring it back one more time. Why are we doing this? Everyone should know. What problem are we solving? Everyone should know. If you stand for nothing, Burr, what will you fall for? *(Alternatively, this song’s item could have been about documentation. You should write things down. Hamilton did.)

It’s that GIF. Someone should ‘shop Hamilton’s face into it.

3. Winning cabinet battles (without alienating designers, developers, Democratic-Republicans, etc.)
Collaboration is messy. It’s wet. It’s about dealing with humans and their feelings and their agendas and their great ideas for the future of the product, the platform, and your users. Lean on quantitative data to make directional decisions, but work with UX/IA/Design as early as possible, develop lightweight prototypes, use qualitative usability testing to find out how real live humans might push the buttons in your hot new thing, and at the end of this, you should end up with a product true to your story, but one that Madison and Jefferson can back without falling back to a literally political compromise.

I guess this is a picture of the Reynolds Affair pamphlet included in a book photographed and found on a Smithsonian website.

4. Learn how to say no to this
There are lots of really well-made blog posts and presentations out there about how to say “no” as a product person of various vintages, and you should read one. This one is my favorite from the last year or so. Here’s Des Traynor’s response to the standard plea to just develop a new feature and make it configurable for the clients/users/markets that want it:

“Making features optional hides the complexity from the default screens in the interface, but it still surfaces everywhere else. The visible cost of this is a messy interface with lots of conditional design and heaps of configuration. The hidden cost is that every optional feature weakens your product definition.”

(I’m not sure how to bring this one back to Hamilton, but you probably shouldn’t do what he did in the Reynolds Affair, either.)

Alexander Hamilton’s grave in Trinity Church. (Real live legit CC photo from Wikipedia, by Nathan Stringer.)

5. The ten (um, five?) [killing a product] commandments
Number one: Why did we do this in the first place? What were the key performance indicators we all agreed on? Are we hitting our numbers?
Number two: Did we give this thing a chance to succeed? Did we launch a new feature and never tell users about it? (Navigation links don’t count as marketing, yo.)
Number three: Does this thing still align with our strategy? Did we pivot, or did leadership change, and did we forget about this thing we were trying to do?
Number four: Are the few users who are engaged with the product valuable? Are they paying for it? Is that revenue worth more than the effort and noise keeping it alive? (OK, these are coming out more like questions, but I’m going to keep going.)
Number five: Technical debt for the sake of a product you’re not marketing and no one is using? Literally the worst. (Shoutout to Biggie Smalls and Lin-Manuel Miranda for writing ten of these with a theme, ugh, this could be another whole post. I’m stopping at five.)

Take a break, there’s a lake I know in a nearby park. (JPG, of a Postcard, of the Schuyler Mansion in Albany, from a library in Boston, on a really nice website.)

6. Take a break
Look, the thing is, you’re obsessed with your product, or your product line, or the features you specialize in, whatever your role may be. You eat/sleep/breathe it, and in a good way, and you’re just flat-out bathing in the roadmap and the stories moving through dev and the bugs and ugh guess what you need a break.

Seriously, if you’re going to maintain your sweet holistic view of your product in context, you need to shift gears, work on something else periodically, have a side project, learn an instrument, get a hobby, stop campaigning to get your plan for a strong central bank through Congress for a couple days in the summer. Cross over into another team, pay other orgs a visit, go to a conference, find a way to recharge and refresh your thinking.

Young, scrappy, and hungry? (A GIF I saw on Giphy that came from Tumblr that probably came from a YouTube video, sourcing is a challenge these days, innit?)

7. Do not throw away your shot
Honestly, there’s a limit to the product management inspiration we should take from the portrayal of Alexander Hamilton in the current Broadway musical. Don’t be so stubborn that you end up in Weehawken facing down Aaron Burr. Or a dev manager. Duels with pistols are to be summarily avoided. As a rule.

But. Still. If you’re in a position to help build something beautiful that helps communicators reach an audience, or helps do an important job for users, take some inspiration from the persistence of Miranda’s Hamilton (or from Lin-Manuel Miranda himself), and fight for the important things and the people who rely the most on your labor. In the end, hopefully, you’re building tools for humans, not just software.