Most teams end up building whatever pushed hardest that week. A pilot customer, a support ticket, an idea from the last stand-up. Nobody sat down and decided this was the process. It simply became one, one reactive decision at a time.
I see this constantly with technically led teams. The technology is often strong, but the product direction becomes reactive when it gets pulled around by whatever’s most urgent, whichever customer is loudest about their ask, or whatever broke last. By the time an insight reaches someone with the authority to act on it, it has already been filtered through sales, support, and whoever passed it along.
Before I build anything for a client, or say anything definitive about their market, I test whether the problem I think I am seeing is actually there. Not because I enjoy discovery for its own sake, but because building the wrong thing faster is not a win.
How I tested my own assumption first
I did not want to take this as given just because I had seen it a few times. So I interviewed 28 tech leaders, founders, CEOs, heads of product, and engineering leads, across companies from seven people to over 400,000, from pre-seed to publicly listed.
Everyone received the same six questions, to make it easier to compare results. Four themes came back consistently:
- No structured process: Teams relied on memory, instinct, and whoever happened to be in the room.
- Single-person filters: One person’s undocumented judgement decided what counted as signal.
- Abandoned feedback: Backlogs of customer input sat unanalysed, with no process to revisit them.
- Disconnected channels: Teams had no way to connect what showed up in one channel to what showed up in another.
That confirmed the problem was real, and not just a pattern in the specific companies I had happened to work with.
Then I proved it against evidence I didn’t control
Knowing a problem is real does not tell you whether your proposed solution works. So I built the smallest possible prototype and tested it against data I had no hand in shaping. I detailed the full technical build and debugging process, the token limits, the point where no-code stopped being enough, in a separate write-up on building the prototype.
The clearest proof came from a company called Kobai. Their Head of Engineering had already manually worked through a backlog of over 400 tickets, spread across ideas, fixes, and customer requests, none of it structured for this kind of review. That manual pass had taken her weeks.
When I ran that same backlog through the tool, the output matched her own understanding of the data closely enough to move the conversation from “does this work” to “what would it take to run this properly.”
That was the test that mattered. Not whether the output looked plausible to me, but whether it held up against judgement that had already been checked against reality by someone with no reason to validate my tool.
Why this is how I work with clients too
The tool itself, Intuifi (intuifi.io), is simply one output of that process. The process is the point: form a hypothesis, test it before committing resources, build the smallest thing that answers the open question, then check it against evidence you do not control.
That is exactly what I bring in when I embed with a technical team. I am not there to install a rigid roadmap template or tell you what to build based on my own read of your market. I am there to get direct access to your customers, test what is actually true against evidence neither of us is shaping to fit a preferred answer, then build the product and commercial narrative from what holds up.
If your roadmap is being shaped by whatever pushed hardest this week, rather than by anything you have actually tested, get in touch and let’s talk.