When 'Not Yet' Points You at the Real Work

I was in a meeting recently that was meant to be about an API.

The sensible outcome would have been to say "not yet" and move on. In practice, that's more or less what we did. We don't have the data foundations, internal capability, or sensible landing place for that kind of integration yet. Wiring something up now would have created the feeling of progress without the substance.

But something else surfaced in the conversation.

What was already there

Not a new requirement. Not a roadmap item. A dataset that already existed.

A CSV file. Public. Occasionally downloaded. Interpreted by a small number of people who knew it well. Useful when someone needed to answer a hard question about the EAC market, but largely inaccessible to others who could have benefited from it — particularly in Sales.

One person on the team had already tried to take it further. Pulled it into Power BI. Taught himself enough to explore it. It worked, up to a point. But turning that into something stable and shared took effort, and was easy to deprioritise against other things.

So instead of escalating the big thing, I chose to explore the small one.

What happened in a few hours

I took the meeting transcript, worked through the decisions people were actually trying to make, and narrowed the scope hard. No live data. No automation. No pretending this was production-ready.

Just a clear snapshot of data people already relied on, presented in a way that made it easier to think.

A few hours later, there was a simple internal dashboard — built through a combination of domain knowledge, Copilot, ChatGPT, and Cursor. CSV in. Cleaned. Shaped. Enough structure to build intuition about the market and ask better questions.

It's being tested now. Parts of it will probably be thrown away. That's fine.

What the speed actually changed

What struck me wasn't how fast it came together. It was that this thing likely wouldn't have been built at all before. Or it would have taken weeks and quietly lost momentum — deprioritised because the effort was too high relative to the uncertainty about whether it would land.

The tools didn't replace the judgement about what to build or the experience needed to shape it. They didn't remove the need to say "not yet" on the API. They lowered the cost of trying something small, responsibly, in the margin of an afternoon.

That's a different kind of value than the big integration story. Less strategic on paper. More immediately useful in practice.

The pattern worth noticing

There's a recurring situation in technology roles where you get blocked on the right thing — the architecture isn't ready, the data isn't clean, the organisation isn't aligned — and the default response is to either keep pushing or park it entirely.

The third option is to step sideways: find the adjacent, smaller version of the problem that's actually solvable now with what you have, and build something that delivers real value while the bigger foundations come together.

This has always been possible. What's changed is that the cost of the sideways step has dropped significantly. The exploratory work that used to take weeks and a developer's full attention can now happen in an afternoon with the right tools and enough domain context to direct them.

The question worth asking when you hit a "not yet" isn't just when the big thing will be ready. It's what the smaller, tangible version of the value looks like — and whether you can build it now.