Who this is for
Those who have built projects professionally or even as hobby and indie projects.
Imagine the moment when you identified a potential improvement in your professional workplace or a solution you badly needed. The birth of such thoughts is dear. With the army of open-sourced and closed LLMs available at subsidized rates, one couldn't hold back from making the thought a reality. The immense pleasure of seeing it built, which used to take days, weeks, or months, is inexplicable. Also, in these moments, one wonders about the novelty and the potential spin-off into business prospects.
So one begins with building the working solution. While at it, the design phase might catch one's attention for improvements. With Claude Design, Google Stitch, and other designers at hand, one tends to iterate endlessly. Such sessions would lead to exhaustion or a prolonged pause from actively building the project.
There comes another phase — the technical implementation and the want of an efficient architecture for extension. There are dozens of ways to build a product. The barriers of programming language or unknown areas are no longer a limitation — given the developer's status from the pre-LLM era, the joy of iterating and envisioning what was once impossible was merely a limiting factor for a thought. So the design architecture evolves with countless iterations.
Fed by activities of design and implementation iterations — there arose morphed ideas from the original. Now the mind rushes to settle between the original and the newly shining arrival of improvements. The decision-making was like choosing between life and death of the very solution.
The stages above are potentially hypothetical assumed realities or could be relevant. But everything before launch stays as a hypothesis. So what are the instruments developers could seek to close this hypothesis? The fight is now not with building or implementing the solutions but with battle-testing the hypothesis.
Pause
Everything before launch stays as a hypothesis. The fight is now not with building — but with battle-testing what you assumed to be true.
The death of the hypothesis is undertaken by putting the solution to use — either for yourself, your team, or your potential customers. So how do you go faster when there are decisions that couldn't be made? You are torn between the thought of imagined gain and loss.
The truth which was not accepted until now is that products are not envisioned and imagined in the minds or on paper, but shaped by data from real usage. What could the usage data mean for us? The battle-testing of assumptions against the user journey. The lesser usefulness of a feature once thought to be the primary pull factor of the solution. The feedback — is the umbrella term — for everything that gets collected when the product is put to actual use. As the creator — we shouldn't dictate the entirety of the product. But the co-creation with user feedback and the person who envisioned building it.
Questions to sit with