A long while back I had a small falling out with a boss. I was a green manager and we were trying to figure out what I needed for headcount. I had no idea how to have that conversation: I just knew “more people == more work done.” After a few back-and-forths, he finally realized I wasn’t getting it, and he said, “Look, I need to know each thing the team is doing, how important you think it is, and what it takes to keep the lights on. Tell me that and we can figure out if there’s something we could be doing differently, or slow down on, or reprioritize.”
Oh.
At the time I was full steam ahead on a Rails app that helped manage technical docs. We’d grown the page count 3x in just over a year, and we were starting to miss things like product screenshots that didn’t change. We also had problems with internal customers telling us they weren’t sure how to tell us about issues. So the Docs Decomposer offered up a rendered view of all our Markdown docs. You could leave a Google Docs-style comment on a selection, and you could also use a bookmarklet with it that let you select a problematic passage and file a Jira ticket with it. It also tracked screenshots and reported on which ones hadn’t changed between versions so we could look in and make sure the product hadn’t changed too much.
Since it was already up and running on internal infra, I just went home and started modeling how my boss had told me how to think about prioritization, and I made a tool that sat in an unlinked page in the Decomposer. You could enter a list of the stuff your team did, then tell it the priority of the item, how well you thought you were doing it, and how much effort it took. If you said something was a P1, but you weren’t doing it well, you got a little “this is on fire” treatment on the priorities report.
So at our next 1:1 I put my browser on the screen in the conference room and walked my boss through what we were up to. We had a great conversation. He thought some stuff we were doing was better left to developers to work on, and he had some stuff he wanted me to emphasize more, and he agreed two more writers for the coming year would be a great idea.
I ended up turning it into an app of its own, adding accounts and separate projects. I developed a practice around it with my teams:
- Dump what you’re doing into the tool.
- Set Priority, Support, and Effort.
- Look for disconnects.
- Renegotiate priorities.
I kept it pretty simple. Each priority has a page that shows similarly prioritized or supported items to give you an idea of what you’re ranking similarly, and there’s a notes field to capture whatever.
It works well with some teams, not so well with others. I’ve learned over the years that you have to help the team keep from spiraling into minutiae, and you need to keep an eye on guilt reactions. But when it works, it’s very clarifying and you can cut a lot of junk out of the backlog.
It’s such a simple idea that it didn’t really need a Rails app. One manager I hired just made his own version in a spreadsheet. Another did Jira reporting with labels. The value isn’t so much the app as it is the thinking process, and having a supportive, thoughtful conversation with your team about what they’re up to, what you can take off their plate, and where their time could be better spent.
Tonight it took about 30 minutes with Claude to get it turned into a PWA that does about the same thing. It uses local storage and you can save it to your phone’s homescreen. I don’t think the app interface is good for a tool like this. It’s meant to be a “put it on the screen and let everyone talk about it,” but I wanted to see how simple it would be to talk through the design and turn Claude loose on it. It took about 30 minutes of back-and-forth. Enough to get it working and convince me it’s not a great idea for phones, but could be a simple webapp that doesn’t need any infra.
People have asked me if I could dig out their logins to it years after we’d worked together, so it works for some kinds of brains. And I’ve thought a lot more about how prioritization works (or doesn’t) since I built it. I like the idea of treating it less like AN APP YOU USE and almost more like an educational tool for people who are new to thinking about prioritization and don’t really have their own model yet.
For instance, just looking at the little report, it could do more to suggest overall backlog health, and it could offer ways to think about disconnects. One thing I never got around to coding in last time but was able to add in two minutes tonight was what to do when something is low priority and getting a lot of effort. It used to be those items got a green checkmark … now they get called out.
Anyhow, fun.