I was a pubic hair away from saying we should toss it and rebuild it.
The data layer underneath Reonomy's products had become too hard to use and too easy to work around. Our entire product depended on data, but there was no single reliable way for every team to get what it needed.
That was only half the problem. The roadmap had too many moving parts. We kept finding interesting features that might help sell to another possible customer instead of narrowing the product around the people we most wanted to serve.
More features did not automatically create more value. Sometimes value was a different product. Sometimes it was making the existing one simpler and more dependable.
The plan was to focus from both ends.
Product needed a smaller target and a stronger answer to two questions: who is this for, and what problem must they solve every day? The technical side needed one clean API for getting to the data behind that answer.
Mocking the API routes was the part that could change our speed immediately. The front-end team could build against realistic responses before the real data was available. The data team could work on collecting, cleaning, and structuring the information at the same time. A mobile interface or a new feed no longer had to sit blocked while every layer underneath it became perfect.
That also reversed a bad habit. We had a tendency to look at the data already available and ask what we could put on a screen. I wanted to start with what the product needed to do, mock the required data, and then figure out how to source it.
The front end did not need to know whether the response was mocked or final. It needed a stable contract. The data team needed a clear target rather than a vague request to gather more things.
None of this required a grand invention. It required a narrow roadmap, a dependable interface, time, and discipline.
I still wanted us to ship faster. I just did not want speed measured by how many features we could spew onto a screen.