Because Agile has no single authoritative body, many terms and concepts are up to interpretation. That is not inherently problematic - these slight differences in interpretation often help people find the solution that best meets their needs. So, to that end, if what you are describing works well in your context, enjoy the success.
However, it is certainly not the only way to look at that. To provide some additional perspective to work with, I can share another way to contrast project vs product in an agile context.
Projects are usually constrained in some way. These constraints can be loose or rigid. For example, I may expect to finish sometime in the second quarter or I could have a deadline of April 3rd. Project are usually also constrained in scope, though in agile projects it is far more common to see outcome-based scope rather than output based scope. For example, a traditional project may detail the changes to be made to a system whereas agile projects may say something like "Reduce average time to complete the 5 most common tasks by at least 20%." Also, agile projects are usually structured differently in that the exact path of the project frequently emerges as the project progresses. This allows for more complex work to be handled and adjusted for effectively. These aren't hard and fast rules however.
Products, on the other hand, are "living" things. A product exists until either the company goes under or the product is end-of-life'd. Many things influence if the product is ideally suited for its environment. Technology, competition, skills of both your employees and your customers, market perception, and more all shift around your product. A radical change in the market could mean that the perfect product today is practically useless next week. Because of this, product development is a constant exercise in reflection and adaptation. In the past, products had been evolved through projects and while you certainly can do that still (and even in an agile way), this is often far too slow.
In this perspective, they are two different ways of working - each potentially useful in the right place, but there is no hard-and-fast rule like you have to start one with the other. Again, that is not to say that what you wrote is incorrect, only that there are different ways to look at it and you need to pick what works in your context.