Case study
A fintech utility brief, redirected into a product people actually used.
Cence came to me with a reasonable brief. It was also a brief for a product nobody was waiting for.
The situation
Cence had funding, a deadline and a spec. What they didn't have was evidence that the spec was the right one.
The brief was for a fintech utility — competent, buildable, and aimed at a category where nobody was looking for another entrant. It solved a problem users didn't experience as urgent.
What happened
I pushed back on the brief before building to it.
We went back to what the underlying behaviour actually was: what people did before they reached for a tool, and where the friction genuinely sat. That reframed the product from a utility into something closer to discovery — a place people came to find things, rather than a place they came to complete a task.
Same team, same funding, same deadline. Different product.
Then I built it. Product direction, scope, and the delivery decisions that keep a launch on schedule when the timeline is fixed and the surface keeps wanting to grow.
The result
24,000 users in under six months, live on the App Store and Google Play.
The version in the original brief would have shipped on time too. It would have shipped to a much smaller audience.
The most expensive decision on most projects is made before anyone writes code: what gets built. Teams rarely lose a quarter to bad execution. They lose it to executing a brief nobody challenged.
What I did for Cence is what the Reality Check does formally — take what a team has decided to build and test whether it survives contact with reality before the money goes in.
Telling a funded team with a fixed deadline that the thing they hired you to build is the wrong thing is not a comfortable conversation, and it is not obviously your job. The spec was not incompetent. It was competent and aimed at the wrong problem, which is harder to argue with than a bad spec.
What made it possible was doing the work before the conversation. I did not arrive with an opinion; I arrived with what people actually did before they reached for a tool. That turns a disagreement about taste into a disagreement about evidence, which is a conversation that can be won.
The timeline was the other constraint. The redirect had to cost nothing in schedule, or it would have been overruled regardless of whether it was right.
Common questions
Why redirect a brief instead of building what was asked for?
Because the brief solved a problem users did not experience as urgent. The category already had entrants and nobody was looking for another one. Building it competently would still have produced a product with a small audience.
Did the redirect cost time?
No. Same team, same funding, same deadline — the product changed, the schedule did not. The redirect happened before code was written, which is the only point at which it is cheap.
What does redirecting a brief actually involve?
Going back to the underlying behaviour: what people did before they reached for a tool, and where the friction genuinely sat. In this case that reframed a utility into something closer to discovery — a place people came to find things rather than to complete a task.
Your turn
Bring me the list nobody's willing to question.
Twenty minutes, no pitch. If I'm not the right person, I'll say so and point you somewhere better.