A general direction has been set, a team of people assembled, they know what their first deliverables are, and they are off and running. They don't know what the end deliverable will look like, nor do they have a set of satisfaction criteria. Neither they nor their customers can say how long the work will last, and drip-feed development could go on for ever. They describe themselves as a project team, but are they really? And is their manager a project manager? Prince2 would suggest not, and I suspect that PMBOK would agree, but it is not an uncommon situation. If this is not a project, what is it?
If the team is working on an ongoing project or series of related projects, it's quite possible that this particular team is part of a program or part of product development.
Wikipedia describes a Program Manager as a person who manages multiple projects and who communicates with one or more project managers in order to meet a specific strategic goal.
According to Project Management Institute (PMI), The Standard for Program Management, 2nd Ed., "A Program is a group of related projects managed in a coordinated manner to obtain benefits and control NOT available from managing them individually. Programs may include elements of related work outside of the scope of the discreet projects in the program... Some projects within a program can deliver useful incremental benefits to the organization before the program itself has completed."
A Product Manager is someone who manages the development of products for an organization. In my organization, this role would best describe what I do, as I am handling cross-functional goals, including development, marketing, sales, customer service, and human resources. Below is the definition of a product manager from Wikipedia:
A product manager investigates, selects, and develops products for an organization, performing the activities of product management. A product manager considers numerous factors such as intended demographic, the products offered by the competition, and how well the product fits with the company's business model. Generally, a product manager manages one or more tangible products. However, the term may be used to describe a person who manages intangible products, such as music, information, and services.
Wikipedia also goes on to say that a product manager may also perform the duties of a program manager and/or a project manager as well as playing a leading role in supervising and setting goals for program and project managers.
In your scenario, your team and manager may cross the lines between being categorized as a product team, program team, or project team, depending on where you are in the process.
I may be breaking the fourth wall by adding this, but I also want to point out that Questions About Product and Program Management Are On-Topic Here.
It depends on how orthodox you are going to be about project. If you take either Prince2 or PMBOK or Wikipedia definition it doesn't make a project.
However personally I'm far from being conservative on definitions and so are many people people out there, so I'd say it is a project.
Actually, many R&D endeavors works like that. Also, in many agile project, you don't have clear completion criteria or it is changing very often, like every couple of weeks -- it just depends how you look at the subject.
What more, if you asked people they would answer they are a project team. The client is probably describing this venture as a project. The vendor probably refers to it as a project as well, so who are we to disagree?
Besides, we don't get points, or get paid, for being conservatively aligned with definitions, whatever they are, but for making clients satisfied. So as long as everyone is happy, I see no issues with breaking rules of one or another specific project management methodology.
It appears you have a Development Team in search of a Project. Their leaser would be a Development Leader. Unfortunately, too much development is done in this manner. However, it appears they do have a direction. Whether, their development approach is appropriate for the ultimate (apparently unknown) goal remains to be seen.
Not knowing exactly what the end deliverable will look like may be appropriate. Not knowing the scope of the project is not. What is the vision of the project? Are they building a bread box or a skyscraper? I would not want to be their customer, and it can be frustrating to develop in such a situation.
Once they have a project with a vision, scope, and satisfaction criteria, they will become a Project Team and their leader a Project Leader.
Personally I would call this a Research (project). But even for a research project, you must have some sort of goal, a problem you want to solve. Is there some stage/level you want to reach before you call it even a small success in its own right (no matter how long it might go on afterwards).
If you can identify a first step quite clearly, then you have it, it is a project.
Another way to look at it is to ask who calls the shots, who pays for it. Is there any criteria for pulling the plug? If there is a defined stage by which some form of result must have appeared or funds dry up and the project team must be dissolved, then there you go again, you have a set of criteria.
I understand that those criteria may not be hard and objective, but I don't know of many endeavours (including personal ones) that don't have some sort of tangible even subjective milestones to reach, for either self satisfaction, or as a decision point to go on to the next step, can the whole thing, or try a different direction.
If the "team" is not working against a defined list of features with acceptance criteria inside of a specified time horizon, they aren't a project team, they are an exploratory committee working on a "spike" (to borrow a term from XP). While completely acceptable, "spikes" are exercises undertaken by a project team when they need more information to better understand the product they are developing and any underlying technical challenges so that they can provide better estimates and risk evaluations.
Someone, somewhere is paying the freight for this effort - they might have some expectation of ROI. How do you define ROI if you have no means of measuring outcomes like what you're building or if it was successful? Agile/lean/iterative/incremental processes are best suited in situations where the end goal is understood but not necessarily how to get there: Risk is managed by continually inspecting and adapting within short time horizons - without goals, this quickly becomes a morass.