How I Saved Opto from Becoming a Feature Factory

I never planned to fix how Opto's product team worked. I was a designer. My job was pixels, user flows, the space between a label and an input field. How four product managers triaged incoming requests was none of my business.

But when you're the only designer at a startup for almost four years, you stop seeing clean boundaries between your job and someone else's. You just see the product. And at some point, I started seeing cracks in how we decided what to build.

The First Signs

It started with sales reps pinging me on Slack. Not the product managers. Not through Linear tickets. Me. One by one, they'd reach out after client calls, sometimes pulling me aside in the office. They had feature requests that weren't going anywhere. Clients were asking for things that seemed reasonable, and those requests just vanished into a backlog nobody could navigate. Deals were at risk and nobody seemed to be listening.

One conversation stuck with me. A sales rep told me about a client who'd asked for the same improvement three separate times over four months. The ticket existed. It was sitting there, lost among hundreds of others, no clear priority, no owner, no timeline. He wasn't angry about it. He was just tired.

When you actually use the product you design every day, user frustration isn't abstract. Every unaddressed ticket is a gap in something you poured months into. I kept thinking about it at night, which is usually how I know something has become my problem whether I want it to be or not.

Stepping into Someone Else's Arena

I was nervous about this. Our PMs weren't doing a bad job. They were drowning in the same complexity I was seeing, just from a different angle. This was a structural problem, not a people problem. But try explaining to someone that the way their team organizes work is broken without it sounding like criticism. I didn't know how to do that yet.

So I started with what I knew how to do: research. I ran structured interviews with every person on the sales team. Real sit-downs, not Slack check-ins. What are you hearing from clients? What feels urgent? What happens after you file a ticket?

Every single sales rep gave me a different answer for what the "top priority" was. One thought the subscription flow was the bottleneck. Another was convinced it was reporting. A third said the onboarding experience was turning off new firms. They were all right, in their own context. But they had no shared language for any of it, and no mechanism for their signal to actually reach the people making roadmap decisions.

Sales and Product had no regular syncs. Sales filed tickets. Product triaged them alongside a hundred other inputs. Nobody knew which tickets to prioritize or why one request mattered more than another. Everything was urgent, which meant nothing was.

Meanwhile, I Was Learning to Code

Around this same time, I had started picking up Claude (the AI coding assistant) and began pushing code directly into our app. Small stuff at first: polishing UI, tightening spacing, fixing visual bugs that would have taken an engineer thirty minutes to context-switch into. Then bigger things. Entire flows. I was shipping meaningful improvements from my own branch.

It was exciting, but it also made me more anxious. If I could push code, and engineers were building features, and PMs were managing competing priorities, and sales was filing requests from all directions, who was actually watching the overall quality of the product? Who was making sure we weren't just adding features, but adding the right ones in the right order?

I had a gut feeling this was going to become a much bigger problem. I just didn't have a name for it yet.

Naming the Problem

I went down a rabbit hole. Stripe's obsession with developer experience as a product quality signal. How Airbnb restructured their product org post-pandemic with a smaller team. Spotify's squad model and why it breaks down. Linear's opinionated product philosophy. John Cutler's writing on feature factories.

That last one stopped me cold. Feature factory.

That was us. Not on purpose, and not because anyone was doing something wrong. We'd fallen into it the way fast-moving startups do: by solving problems one at a time as they arrived. Sales raised an issue, a PM wrote a ticket, an engineer built it. The individual features were fine. We just never stepped back to ask whether we were solving the right problems in the right order, or whether there were system-level improvements that could eliminate ten tickets at once.

Every team was solving their own slice of it. The bigger questions (architectural decisions, cross-cutting improvements, ideas that didn't fit neatly into a sprint ticket because they weren't "requests") had no home.

The Framework

What I proposed was simple. Not a new process or tool. Just a way of categorizing every request, ticket, and idea that entered the product backlog into one of four buckets:

Quick Fixes: bugs, UI issues, small friction points. Ship within a sprint. The cost of ignoring these is slow trust erosion with users.

Product Improvements: enhancements to what already exists. Better search, smoother onboarding, faster load times. Makes the product better without changing what it does.

Product Capabilities: new features that extend what the platform can do. Planner & Pacing, Bulk Import, Proposals. These unlock new use cases or unblock adoption.

Innovation: net-new bets. Radar. AI Due Diligence. These don't come from tickets. They come from vision, and they open entirely new revenue streams.

Obvious in retrospect. But the power wasn't in the labels themselves.

What Changed

Once people started using the categories, a PM could look at a sprint and say: "We have twenty Quick Fixes, eight Improvements, two Capabilities, and zero Innovation." Before, that sprint would have just been "thirty tickets, prioritized." Now you could see the shape of it. You could see the gaps.

Quarterly roadmap planning shifted too. Instead of debating individual tickets, teams allocated capacity by category. Maybe this quarter is heavy on Quick Fixes because we have a lot of debt. Next quarter, the mix shifts toward Capabilities. The conversation went from "Feature X or Feature Y?" to "what kind of work does this moment demand?"

Sales could finally communicate in a way that actually landed. Instead of "here's another ticket," they'd say: "This is a Product Capability request, three firms are blocked on it, and it's the top reason we're losing competitive deals." That carries more weight than a Linear ticket with a priority flag because it maps directly to how roadmap decisions get made.

And Innovation, which never had a home before, got permission to exist. Any idea that wasn't a direct response to a ticket used to feel like a luxury. Now it was a recognized category with its own allocation. That's the environment that got Radar greenlit and produced AI Due Diligence.

What I Learned About Myself

I almost didn't do any of this. I almost stayed in my lane, kept designing screens, and let someone else figure out the organizational stuff. I kept thinking: who am I to tell four PMs how to structure their work? It felt like overstepping.

Looking back, I think that's part of why it worked. I wasn't coming in with a critique or a power move. I'd sat with the users (directly and through sales) and felt their frustration in my own work. I wasn't trying to fix a process. I was trying to advocate for the people using the thing I designed.

The thing I keep coming back to: the most impactful work I did at Opto had nothing to do with pixels. It was research, empathy, and a framework simple enough that people actually adopted it.

Four PMs now use this framework for sprint planning and quarterly roadmaps. Engineering allocates capacity against these categories. Sales communicates in a way that maps to how decisions actually get made.