Work the Problem, Not the Ticket

A ticket hits the team: "Add a button to export to CSV." Seems straightforward enough. Your team picks it up, adds the button, ships it. Ticket closed. On to the next one.

A week later, three more tickets arrive. The marketing team needs the export in a different format. The sales team discovers the exported data is missing fields they need. The finance team realizes they need to schedule recurring exports. This “simple request” turned into a firehose of additional work that the team hadn’t considered, all urgent now and demanding attention. 

This is the problem with the idea of working tickets instead of solving problems.

The best way I can describe this is like “Coin-operated IT,” and unfortunately many product development teams fall into this pattern. A ticket comes in, someone works it, something goes out. Like operating a helpdesk where you’d apply the same logic to fixing broken laptops: a user submits a ticket saying "screen is cracked," a technician replaces the screen, the device gets returned. Input, process, output. Repeat.

This approach might work when you're actually repairing hardware. The problem is well-defined, the solution is known, and the scope is contained. But software development doesn't work this way. In an increasingly complex environment where businesses are becoming more sophisticated and development velocity continues to accelerate, treating requests as discrete work units doesn't just fail to scale; it actively creates more work (and more complexity).

Because requests don't exist in isolation. They have upstream causes and downstream implications. They affect multiple stakeholders in ways that aren't always obvious from the ticket description. And they often represent symptoms of larger problems that will keep generating more tickets until someone stops to address the root cause.

If your team is working tickets, you're solving the wrong problem.

Symptoms, Not Problems

Tickets aren’t work, they’re symptoms. And you don't fix symptoms. You diagnose them.

When someone submits a request for a CSV export button, that's not the work. That's a signal. The real work is understanding what problem they're trying to solve. Are they manually compiling reports every week? Are they trying to get data into another system? Are multiple teams doing similar work with slightly different needs? Is there a broader workflow that's broken?

The ticket is the beginning of a conversation, not the end of one. But many teams treat it as a complete specification because it's faster, it's easier, and it lets them show visible progress. They're optimizing for delivery: tickets closed per sprint, velocity metrics, that satisfying feeling of moving things across the board.

What they're not optimizing for is impact.

When you work tickets without diagnosis, you end up in a cycle of reactive work. You solve the immediate request, but you miss the opportunity to solve the actual problem. The symptoms keep reappearing in new forms, generating more tickets, creating more work, and consuming capacity that could be spent on strategic improvements. And because of this, it can lead to insurmountable amounts of technical, product, and design debt that your team will spend years trying to dig themselves out of.

The Real Work Behind the Request

So instead, when a request comes in, you dig in. You diagnose. You talk to the person who submitted it and the people who will be affected by it. You ask what they're trying to accomplish, what their workflow looks like, what success means to them. You surface the constraints and assumptions they're working under. You look for patterns across multiple requests that might point to a systemic issue.

You're trying to understand the outcomes they're driving toward, not just the output or solution they've asked for. Because many times, what someone requests isn't actually what will solve their problem. They're constrained by their understanding of what's possible, by the systems they currently work within, by the solutions they've seen before. Your job is to understand the problem well enough to identify the right solution, which may be quite different from what was requested.

This also means considering the secondary and tertiary implications. Who else will be affected by this change? What adjacent use cases exist that you could address at the same time? What new capabilities does this unlock? What technical debt might you create if you implement this narrowly? How does this fit into your broader roadmap and strategy?

And most importantly, it means defining what success looks like across all stakeholders, not just the requester. How will you know if this actually solved the problem? What metrics will tell you if it's working? What failure modes should you watch for? What's the plan if this doesn't achieve the intended outcome?

Only after this diagnosis and exploration does the request become work. Real work. Work that delivers meaningful value and reduces the number of future tickets rather than generating more of them.

The Range of Requests

Of course, not every request requires deep research. There's a range here, and part of effective diagnosis is knowing where in that range any given request falls.

Some requests genuinely are straightforward. Password resets. Access provisioning. Configuration changes. These exist, and they need quick responses. But even with these, you should be looking for patterns in aggregate. If you're getting dozens of password reset requests every week, that's a symptom of a larger authentication or user experience problem. If access requests always come through ad-hoc tickets, maybe you need a self-service system.

Sometimes understanding the difference between what should be a simple change request and what actually needs exploration comes down to asking quick clarifying questions: "I can get this done today; just want to confirm this solves what you need and there isn't a broader need I should be aware of." Often the answer is "yes, this is exactly right." Sometimes it's "actually, now that you mention it...." The default should be to ask questions first, especially when the ask involves building new capabilities, changing workflows, or touching systems that affect multiple teams.

Why Teams Work Tickets

Despite the fact that we know we want to be driven by impact and business results, not simply delivery metrics, this [anti-]pattern of behavior happens for very real and very justifiable reasons.

There's pressure for visible velocity. Management wants to see progress. Stakeholders want to see their requests addressed. Teams want to demonstrate they're being responsive. Working tickets provides clear, measurable output: look how many things we shipped this sprint. It feels productive in a way that "spent three days talking to stakeholders to understand the real problem" often doesn't, at least not in the moment.

There's also pressure from being under-resourced. When you're already stretched thin, taking time to dig into every request feels like a luxury you can't afford. It's faster to just build what was asked for and move on. The fact that this creates more work later is a tomorrow problem.

Sometimes the pressure is more subtle. In some organizations, being "low-touch" and "easy to work with" is rewarded. Teams that ask lots of questions or push back on requests get labeled as difficult or slow. It becomes safer to just say yes and build what was asked for, even when there’s that nagging feeling it's not quite right.

And sometimes it's just organizational inertia. If the team has always worked that way, if that's how work has always flowed through your team, it takes conscious effort to break the pattern. Especially when the person who submitted the ticket not only seems confident in what they want, but has historically been the “subject matter expert.”

These pressures and constraints are real, but the tax on the team is also real. You're not actually moving faster if you're constantly generating more work. You're not actually being helpful if you're solving the wrong problems. And you're certainly not being strategic if you're operating in a purely reactive mode.

Making the Shift

Breaking out of the ticket-working rut starts with reframing how you think about requests.

Every request is an opportunity for critical thinking and discovery. What can you learn about how your users work? What pain points are they experiencing? What patterns are emerging across multiple stakeholders? This mindset shift changes the conversation from "what did you ask for" to "what problem are you trying to solve?"

It also means educating stakeholders about what makes a good request. Not just "here's the ticket template," but helping them understand that the more context they provide about the problem they're trying to solve, the better solution your team can design. When stakeholders understand that you're trying to help them succeed, not just check boxes, they usually become more willing to engage in that discovery process.

You also need to close the feedback loop. When you dig into a request and discover that the real problem is different from what was asked for, you need to communicate that back: "You asked for X, but after talking with your team and a few other stakeholders, here's what we propose to build and why we believe it's better." This builds trust and helps stakeholders understand that your questions aren't obstructions; they're part of delivering better outcomes.

Practically speaking, this might mean building discovery time into your planning processes. Not every story can be estimated accurately until someone has done initial exploration. It might mean pairing more senior team members with less experienced ones on request intake, so everyone develops stronger diagnostic skills. It might mean implementing a lightweight triage process where requests get categorized by complexity before work begins.

It Takes a Village

The ability to work problems instead of tickets doesn't happen in a vacuum. It requires organizational support and alignment.

Leadership needs to value impact over output. If your team is being measured primarily on ticket velocity or story points, you'll get ticket-working behavior. If leadership understands that fewer, better solutions are more valuable than many quick fixes, they'll support the time investment in proper discovery. Incentives drive behavior.

Product and engineering need to be true partners in this. Product Managers should be spending time with stakeholders understanding problems, not just collecting feature requests. Engineers should feel empowered to ask "why" and keep pushing for full definition of requirements that seem incomplete or misaligned. When both sides of the partnership are focused on outcomes, it becomes much easier to resist the pull of ticket-working.

The people submitting requests play an equally important role. A good request includes context about the problem being solved, not just the solution being requested (and this is not to say that the solution shouldn’t be included in the request either, as the requester’s instincts and desires are incredibly valuable signals.) It explains who is affected and what success looks like. It acknowledges uncertainty and invites collaboration rather than presenting as a complete specification. These kinds of requests make it much easier for teams to do good diagnostic work.

But expecting stakeholders to naturally submit perfect requests isn't realistic. Most people aren't trained in software development or product thinking. They're expressing their needs in the best way they know how. Part of your job is teaching them, over time, what kinds of information help you help them better. When you consistently respond to requests by asking good questions and then delivering better solutions than what was asked for, stakeholders learn to bring you problems instead of solutions.

The Long Game

When you shift from working tickets to solving problems, the benefits compound over time. You build fewer things, but each thing you build has more impact. You prevent future work by addressing root causes instead of symptoms. You strengthen relationships with stakeholders because they see that you're truly trying to help them succeed, not just check boxes.

Your team develops better judgment about what questions to ask and when to dig deeper. They get better at seeing patterns across requests and identifying opportunities for strategic solutions. They develop confidence in pushing back on incomplete requests and advocating for time to do proper discovery.

The organization starts to trust that when work goes to your team, it comes back better than what was asked for. Stakeholders begin bringing you problems instead of solutions because they've seen that you'll design better solutions than they could have specified. The nature of the work changes from reactive to strategic.

But perhaps most importantly, your team finds more meaning in their work. Building well-understood solutions to real problems is more satisfying than cranking through tickets. Seeing the impact of your work when you know you've solved the right problem is more rewarding than just closing tickets. This isn't just about efficiency; it's about building a team that does work that matters.

So every time you choose to ask "what problem are we really solving?" instead of "what did the ticket say?", you're making an investment: in better solutions, in fewer future tickets, in stronger stakeholder relationships, in more meaningful work. The returns on that investment may not show up in this sprint's velocity metrics, but they'll show up in your team's impact, in your stakeholders' satisfaction, and in the long-term sustainability of how your team operates.

Stop working tickets. Start solving problems. The tickets will take care of themselves.