Context
A low-code platform that “turns data into solutions” is a promise wide enough to swallow a startup. The team was capable and the technology worked. The risk was the usual one: a roadmap built from every prospect’s request, and no way to tell which requests were the product.
What I did
- Worked through who the platform was actually for, and — harder — who it was not for. A low-code tool aimed at both analysts and engineers usually ends up serving neither.
- Pushed for a small number of end-to-end use cases that could be demonstrated completely, instead of many capabilities that could each be demonstrated partially.
- Reviewed the technical bets: what to build, what to buy, and where a dependency on a fast-moving model provider was an acceptable risk versus an architectural trap.
- Coached the delivery practice — estimation, release cadence, what to measure — so improvements landed on a schedule rather than in bursts.
Outcome
A narrower product with a clearer buyer, and a team that can ship and measure on a predictable cadence rather than by heroics.
What I’d do differently
I would have pushed harder, earlier, on saying no. Mentoring makes it tempting to offer options and let the team choose. When the failure mode is scope, options are not what the team needs; a clear recommendation with the reasoning attached is more useful, and it is still theirs to reject.