The Art of Product Framing
Solving the RIGHT problem is your ultimate leverage
In the world of product development, the way you frame a problem can be the difference between success and failure. That is why communication, a broad knowledge base, and a willingness to understand exactly what the problem is are so important; only then can you begin to think of a solution.
There was this one time I participated in a project for an app where the client wanted to build it practically from scratch, a kind of CRM projected to become a super app with countless features over the following months. At that moment, I was the main person responsible for the architecture and development from the ground up.
But there was a problem on the client's side: they had almost no idea what the screen designs, the user flows, the API communications, the distribution, and other details would look like. And sometimes, that's just how it is, you won't always have all the cards and details on the table.
The best justifications for the app were related to the money they would save and a few samples of how they were currently operating. However, the proposal for the app was that it had to be special, completely different from everything they already had. Well, the main reason they had chosen Android/iOS apps is the convenience, flexibility, and mobility they offer.
As I carefully analyzed the scenario and the problems, it clicked: I noticed a pattern in what they truly needed, so I decided to sketch it out in a flowchart. Through that diagram, I realized that, at that moment, the app actually only needed two main recursive screens. Yes, just TWO screens!
I presented it, and the client really liked it, both for its simplicity and because it gave them a clear foundation for the core of the app they actually wanted. Right after that, I developed a small prototype so they could better visualize the result and give more feedbacks. The project was a success and, of course, evolved over time with more data, screen flows, complexities, and business rules.
The big lesson here is: imagine if I had rushed in and developed everything right away? If I had unnecessarily architected the database layer and flooded the project with a whole architecture, numerous packages, files, and related classes? I most likely would have wasted a huge amount of everyone's time and energy, only to frustratingly realize later that it was the wrong path, since the foundation of what the client wanted was much simpler than it initially seemed.