I Got Tired of Scrolling, So I Shipped Code Instead

I shipped code last week. As Head of Product, I merged a PR that added a search field to an internal admin tool. It took less than an hour using Cursor, and it felt great.

Here's the thing: it had zero impact on revenue, user acquisition, or retention.

And here's the other thing: it's completely fine.

The Problem

For weeks, I've been scrolling through an unsearchable list of usernames every time I need to manually assign someone to the products we are building. It's a 15-second tax I pay multiple times a week. Life-altering? No. But given I'm also juggling everything else that comes with being Head of Product, these small frictions take their toll.

There's the context switching. The "ugh, I hate this so much" feeling every single time. Knowing how my brain works, that thought can lead to a shift in my mood. When you're trying to work quickly, maintain momentum, and stay in a learner's mindset, even the most minor shift can make a significant difference.

I could have talked to an engineer about it. But that felt like a waste of time. Am I really going to ask the engineers who are deep in agentic architecture work to context-switch for this?

As I am the person who sees a problem and then figures out the solution, I decided to stop dealing with it and fix it myself.

The Solution

I cloned the repo, paired with Cursor AI, and coded a small quality-of-life enhancement. Added a search field. Drafted a PR. Had one of the devs review it.

It's now live.

I've officially contributed to our codebase as a product person.

Does It Matter?

If you're looking at product metrics, this contribution is invisible. It doesn't:

• Drive revenue
• Improve user acquisition
• Boost retention
• Reduce churn
• Speed up customer onboarding

And that's precisely the point. By fixing this myself, I:

• Removed cognitive friction that was hitting me repeatedly
• Preserved engineering capacity for features that do indeed move business metrics
• Maintained team focus on the work that actually drives revenue

Product Work Isn't Always About the Dashboard

As product people, we constantly make trade-offs about where to invest engineering time. Every ticket we add is saying, "This is more important than everything else we could build."

A search field in an internal admin tool? That's never winning the prioritization battle when we're building enterprise-grade AI infrastructure.

But accumulated friction has real costs, not just in time, but in decision fatigue, context switching, and that mental "ugh" every time you encounter it. These paper cuts compound. They slow you down. They shift your mood. They create drag on the whole team.

As someone who values collaboration, I've never subscribed to the notion of hard rules about "this is product work, this is engineering work." There have been lanes, but that's been out of necessity more than ideology. I'm not an engineer, so some things were simply outside my capabilities.

Now? With tools like AI augmenting my workflow, I can make different decisions. I can be empowered. I can let engineers focus on what they do best: handling very complex work.

Am I going to show up tomorrow and tell the team I've completely refactored our permission management system? Absolutely not. This PR will never show up in a board deck. It won't justify my salary. It won't win me a promotion. And that's exactly why it mattered, because I stopped waiting for it to "count" and just made the day-to-day work 1% less annoying for everyone who touches this tool. However, not every problem deserves a mention in a standup. Some just deserve a PR.

*.*