Is Your Strategy App a Product, or a Ticket Queue With a Login Screen?

Ticket Queue vs Product Mindset: Same Skills, Different Operating Model

A ticket queue delivers what was requested and closes the ticket. A product mindset treats each request as evidence of an underlying need, builds the general pattern once, and measures whether anyone actually used it. The skills are identical; the operating model around them is not.

Trace the history of almost any internal strategy app and a pattern appears. A team asked for a goal tracker, so one was built. A director asked for an extra field, so it was added. Finance wanted a quarterly export, operations wanted a different scoring rule, and a new executive wanted a dashboard in the board’s format. Every request was reasonable, and every one was delivered.

Read that history end to end and you are not reading the story of a product. You are reading a list of closed tickets. That difference, between software shaped by requests and software shaped by a product mindset, is one of the least discussed reasons internal apps struggle to serve a whole enterprise.

This is not a criticism of IT teams or of the engineers in them. An engineer in an internal IT department and an engineer at a software company may have identical skills. What differs is the system around them: how work arrives, how it is prioritized, and how success is measured.

Most IT organizations are designed to run systems reliably and respond to the needs of the business. Work arrives as requests. It is prioritized by urgency and seniority. Success means requests fulfilled, service levels met, and projects delivered on time and on budget. That model is exactly right for much of what IT does. It is a poor fit for building software that thousands of different people must choose to use.

What Does “Done” Mean in Each Model?

In a ticket-driven model, work is done when the ticket closes. The feature was requested, built, tested, and delivered. The requester is satisfied, and the team moves to the next item in the queue.

In a product model, shipping a feature is the start of the work, not the end. The real question is whether it changed anything: did people use it, did it help them, did the strategy process improve? Product teams watch what happens after release and expect to revise, simplify, or remove what does not work. A ticket queue has no step for that, because nobody files a ticket to ask whether last month’s feature mattered.

A Request Is Not a Requirement

A ticket records what someone asked for. It rarely records the problem they were trying to solve, and even more rarely whether other people share that problem. A product team treats each request as evidence about an underlying need, then asks how that need appears across every kind of user before deciding what to build.

Often the right response is not the thing requested. Sometimes it is a more general capability that serves ten teams at once. Sometimes it is a change to an existing feature. Sometimes it is a polite no. Saying no is one of the most important skills in product development, and one that a service-oriented IT model is designed to avoid.

The Two Operating Models Side by Side

Why the App Ends Up Mirroring Whoever Asked

In 1968, the computer scientist Melvin Conway observed that organizations tend to design systems that mirror their own communication structures. The idea, now known as Conway’s Law, has a direct application here. Software built through a request queue ends up shaped like the queue: it reflects who asked, how loudly, and in what order.

That is why so many internal apps fit the team that commissioned them perfectly and feel awkward to everyone else. The first team’s vocabulary, review format, and assumptions are built into the screens. When the app spreads to other functions, regions, or acquired businesses, they find a tool designed around someone else’s way of working.

Enterprise Software Needs Abstraction. Tickets Produce Special Cases.

Building software that works across an entire enterprise requires a particular discipline: finding the general pattern behind many specific needs and building that pattern once, in a configurable way. When a product team receives a request for a custom field, it asks whether the real need is for configurable fields that every customer can define. It builds that capability, and the request is satisfied along with many others.

A ticket-driven team builds the field. Then the next field, and the next exception to the scoring rules, and the next team-specific report. After two years, the product has a flexible foundation and the internal app has hundreds of special cases, each of which must be understood, tested, and maintained.

AI coding tools do not change this dynamic. They accelerate it. When each special case takes minutes rather than days, the internal app accumulates them faster, and the gap between a queue of features and a coherent product widens more quickly.

Adoption Is the Metric No Ticket Captures

Strategy software depends, more than most enterprise software, on voluntary and sustained participation. Nobody is blocked from their work if they skip a weekly check-in. People simply stop updating their goals, and the strategy process weakens quietly over a few quarters.

Product companies watch this closely because their revenue depends on it. They track who is active, where people drop off, which features are ignored, and which parts of the organization have disengaged, then design to win those people back. In a ticket-driven model, disengagement is invisible. Nobody raises a ticket to say they have stopped using the app, so the queue looks healthy right up to the point where the program has stalled.

The Move From Project to Product Is Hard

Many IT leaders recognize this problem and are working on it. Mik Kersten’s book Project to Product, published in 2018, set out why the shift from project-based delivery to product-based delivery matters and how difficult it is in practice. It involves changing funding, team structures, measures of success, and the relationship between IT and the business.

Organizations on that journey deserve credit, and the progress they make is real. But it raises a practical question. Is the organization’s strategy system the right place to learn product thinking? Or should that hard-won capability be pointed at the products and services that set the business apart, while strategy execution runs on a platform built by people for whom product thinking is the whole job?

That is the same trade-off the position paper for this series frames as core versus context: every engineering hour spent on context is an hour taken from core.

How Do You Tell Which One You Have?

A few questions quickly show whether an internal app is being run as a product or as a queue.

• Who measures whether people actually use it, and how often is that reviewed?
• What proportion of requests were declined or reshaped in the last year?
• How were the last ten changes chosen?
• Has anyone designed for the least engaged user in the most different part of the organization?
• Is there a roadmap beyond the current backlog?

If the answers point to requests, urgency, and closed tickets, the app is a queue with a login screen. That may serve one team well. It will struggle to become the system that runs strategy across an enterprise.

AI has made the code cheaper. The hard part of enterprise software was always the mindset behind it: generalizing instead of accommodating, measuring adoption instead of output, and treating every release as a question rather than an answer. Organizations should point their own product capability at what differentiates them, and buy strategy execution from people for whom it is the product.

Profit.co works on exactly that operating model. Its product team turns requests from many organizations into platform capabilities, ships each change to every customer at once, and records it on the release updates page, so a team that buys it receives a roadmap rather than a ticket history.

One of the clearest places this difference shows up is the strategy method itself, which most internal builds hard-code on day one without realizing it.