From "projects" to "products"

A product is a long-lived thing that gets made and often sustained/maintained. Projects are temporary efforts to create or modify products or services. Not all organizations create products - sometimes, they deliver once (or a discrete number of times) and never have the longer-term sustainment or maintenance.

You don't need products to shift to agility. Although, if you do have products, shifting toward a product-centric mindset is valuable, but even that doesn't mean ignoring or eliminating projects.

When a team already use "Scrum" since a lot of time, but behind the scenes there is no one real/clearly defined "product", just one project after other (with its deadlines), how would eventually that "switch" from project to product (e.g. during an Agile transformation) occur?

Without a clear line of sight to product value, what evidence is there Scrum is being used at all? How does a Product Owner account for value to stakeholders Sprint by Sprint?

Would the main impacts come from making the client (as "the one asking the business demand") aware of the benefits of Agile in order to change his mindset (and the organization's overall one) and the way budget finances the team work?

Do you know what outcomes the client and organization are hoping to achieve, and why they think an empirical framework would help?

Thank you very much @Thomas Owens for this clarifying perspective!

Thanks @Ian Mitchell for your valuable questions.

I would say that at this stage, the product definition is a bit too wide, still not enough defined or communicated at all levels. Nonetheless, the company is interested in being Agile (mainly for a faster answer to change) and I would say Scrum is adopted as a vehicle (which I would say it is a journey itself, isn't it?) to enhance agility. What do you think about it?

Secondly - please correct me if you think I am wrong - I guess one of the first steps when adopting Scrum in an already existing organization (already offering services/"products" every day since years) would be clarifying what is the product (and its boundaries) we are developing, and after that (explore) what would be the value it can deliver to the customer (and the customer outcomes) and to the organization, and not the other way around. For starting a new "business", probably I would define the product starting from the customer and its value. Would you agree?

Having clearly defined products is not only one of the first steps toward adopting Scrum, but I'd go so far as to say that it is essential for the long-term success of the business. If you don't have well-defined products with a vision for how they fit into the market or support the customers and end-users, how can you do things like accept or reject requests for new capabilities or budget for investments or forecast staffing needs or identifying new product/service opportunities? When you don't have clear product definitions, you end up with a mess, and when this mess gets into how the product or service is implemented and delivered, it tends to slow the delivery down or negatively impact product quality.

There are probably many different ways to define your products, but starting with customers (and end-users - they may not be the same) and the value the product offers to them is probably a very reasonable starting point.