​Developer in Discovery: profit for the product

With a casual movement, the programmer disguises himself as a product developer.
And now he can already participate in the development of the task at an early stage.

Working through the task, the developer gets a ton of motivation to implement it later. This is now your task, from start to finish.

How can it help?

📌 First of all, technical expertise.

1. Roughly estimate the cost of developing even a crude task.
   You don't have to spend time working through space-based tasks with questionable results.
2. Offer a solution to the product problem according to the Pareto principle.
   Sometimes cutting 20% of the volume of a business task saves 80% in development resources. Important: this should not mean a reduction in the quality of the solution.
3. Knowledge of the system's sore spots allows you to push through refactoring tasks.
   After refactoring, a portal opens to the engineering paradise, from which features begin to pour. We accidentally added a new payment method to the payment form 🙂
4. Frankly delusional fantasy solutions can be cut off at an early stage.
   It is better to learn more about the problem and then offer an adequate technical solution.
   In this case, you don't have to figure out how to draw red lines in green.

There were more points. For the convenience of the reader, I have divided the post into two. Separately, we will talk about how to use the other hemisphere of the developer.