Don't Tell Me What to Build. Tell Me What They Actually Want. | Active Logic Insights

We build our own software. Not just a CRM and a sales pipeline, though we run those too. We built the system that tracks every project we deliver: the tasks, the sprints, the reporting, the roadblocks. We are loud about custom software being the right call for most established companies, so we practice what we preach and run the company on software we wrote ourselves. That is the backdrop for this story, not the point of it.

The point is a small request that arrived as an instruction, and what happened when I refused to treat it as one.

A reasonable request, relayed as a command

Every week we send our clients a Pulse Report. It is a high-level summary of the current sprint, written for leadership: what got done, what is coming next, and where the roadblocks are. We keep the functionality runway small, attainable, and measurable, so the report stays honest and the progress stays real.

One client wanted more. Their work spanned an epic, which is just a grouping of sprints. The industry insists on Task, then Sprint, then Epic, and I did not invent the naming. Their leadership wanted to see how the whole epic was tracking, not only the current sprint. Completely reasonable, and exactly the kind of thing that surfaces on a weekly client call.

One of our engineering directors, who runs that engagement, talked it through with the client and came back with a solution: add a few optional fields to the report generator, answer some questions about the epic, and let the status flow into the report. By the time that reached me, the person who owns our internal software, it had compressed into two words. Build this.

He was not wrong, and that is the part worth sitting with.

The instruction is a symptom, not the spec

I do not like being handed instructions. Not because the people handing them to me are careless, but because an instruction is the end of someone else’s thinking, and I am the one who has to live with the result inside a system I know better than anyone.

When a request reaches me as “add these fields,” I rewind it. What does the client actually want, and why. The director had done something generous here. He took the client’s need, designed a fix on the spot, and handed me the shortest path to closing the ticket. That is going above and beyond, not cutting a corner. But a solution built to minimize the time between request and delivery is optimizing for the wrong thing when the person at the keyboard can see further down the road than the ticket does.

The request also degraded as it traveled. The client described an outcome. The director translated it into a feature. By the time it reached me it was a command. Every hop stripped a little of the “why,” and the “why” is the only part I can build well from.

Ask who has to live with it

The fields would have worked exactly once.

They were optional, and they did not apply to every project. So the people who write our reports every week would have had to remember to fill them in, on the specific projects where they mattered, forever. They would forget. Not because they are sloppy, but because an optional field that applies sometimes is never top of mind. I would be shipping a feature engineered to be skipped. Call it the forgotten field: the optional manual step that quietly never gets used, so the capability you paid to build never reaches the value it promised.

This is the part that gets skipped, and it has nothing to do with engineering talent. It is a user-experience question, and user experience here is not a job title, it is a need that somebody has to own. Who runs this thing on an ordinary Tuesday, and will they actually do it. In this case I owned that lens, because I could see the report writers needed a way to give leadership the epic view, and I was not willing to solve it by adding to their plate.

Ask where the system is going

The deeper reason “add a field” was wrong is that I know where this product is headed. Some of the roadmap is written down. A lot of it lives in my head, because I run the project.

The client did not actually want a field on a report. They wanted status on a grouping of work, and our task system did not model that grouping. It understood tasks and what got finished inside a window of time, which is exactly why the report was good at sprint progress. It had no concept of an epic at all. The honest fix was not to describe the epic in the report. It was to teach the system what an epic is.

So that is what we are building: real epics in the task-management system, a first-class grouping of tasks that every project can use. Once it exists, epic status is not something anyone types into a report. It falls out of how the work is already organized. The report writers do nothing new. They group tasks, which they do anyway, and the rollup is simply there.

Weigh the work, then pick the move

None of this means the methodical path always wins. It does not.

If our task system could not produce the data, I would have added the field. If we had no integrated task system in the first place, I would have added the field, because that would be the only way to get the client what they needed in time. The decision is not a principle you apply blindly. You weigh the work against the value and the lifespan of the thing you are about to build, on each request, and you make the call. There is no universal rule that says rework beats bolt-on. Sometimes the bolt-on is the right answer and the elegant version is a waste of everyone’s time.

What I will not do is pretend the shortest path is free. A bolt-on that creates ongoing manual work, on a system that will outlive the ticket, is borrowing against the future. Sometimes that loan is worth taking. You should at least know you are taking it.

The quick win should have leverage

Here is what I actually shipped first, and it was not the epic feature, because the client needed something this week.

Our Pulse Report leans heavily on AI. So instead of hard-coding new fields, I built a guardrailed freeform layer that lets whoever runs the report shape it with a prompt. The director could immediately generate the epic view the client asked for, using a capability I wanted to add anyway: the ability to bend the report to any nuanced situation, not just this one. That was the quick win. It cost the report writer a little effort, but it answered the client now and it works for the next ten requests like it, not only this one.

That is the distinction that matters. A quick win and a bolt-on are not the same thing. A bolt-on solves one request and leaves debt behind it. A quick win with leverage solves this request plus several you have not received yet, and it buys the time to build the proper structural version underneath. From a request that arrived as “add a field,” I got to satisfy the client now, advance the roadmap, and avoid taxing my team forever.

This is the line between good and bad software

Across the 200+ projects we have delivered, the requests that age worst are the ones we built exactly as written.

At the scale our clients operate, they are not buying a working feature. They expect reporting, feedback, and information that fits the way their organization already runs, because their leadership consumes it the same way they consume everything else. You do not get there by executing instructions. You get there by treating every “build this” as a question in disguise: asking what they actually want, who has to live with the answer, and where the system is going, then choosing the move that serves all three. Done right, that is not the slow path. It is the only one that scales.