It does make sense to have some differentiation, however, the proposed differentiations don't make much sense to me.
First, it seems like you're using "ops" and "DevOps" interchangeably when they aren't.
Operations is a type of work. Operations, or ops, means different things to different organizations. I see it as the set of work needed to take a designed system and make it useful to stakeholders. Ops includes packaging the software, building infrastructure, deploying the solution, configuration, and monitoring the hardware and software.
DevOps is a mindset or culture that is designed to consider operations earlier in the systems development life cycle. Rather than a software team building something and going through a hand-off procedure, the ability to package, deploy, configure, and monitor the system is considered early in the initial requirements and architecture decisions. This helps to prevent rework and reduce the burden of operationalizing the system.
There are many ways to achieve DevOps. Some organizations embed operations expertise on development teams on a full-time basis. Other organizations may have an operations team that supports the development teams by conducting training or lending specialists as needed. There isn't one organizational structure needed for DevOps, as long as operational concerns are considered throughout the design and development process.
Second, there probably shouldn't be a distinction between engineering activities and functionality development activities.
Operations is a part of product design and development, as long as the organization that is designing and building the system is the same as the organization operating the system. Not all organizations do both. For SaaS solutions, the same organization will likely build, deploy, and operate the system. However, for some on-premises software, one organization will build the solution while another deploys it into their infrastructure and maintains it.
For organizations building and running the software, operations is usually a part of the engineering organization, which includes the development and product quality organizations. Engineering tends to be a part of a larger product organization, which may include product management, project/program management, and user experience organizations. Depending on the organization, groups such as technical support, sales, and marketing may or may not be part of the product organization.
I find that a better way to look at the work is to divide it into two or three sections. If you wanted two divisions, I would consider "discovery" and "delivery".
Work like software architecture, software design, software construction/implementation, build, integration, test, release, deployment, and monitoring are all part of "delivery". Requirements engineering, user experience design (which includes analysis of AB testing and other analytics), and software architecture are all part of discovery. The two blend around software architecture and design, where the identified needs of stakeholders are transformed into something useful.
There are other ways to divide up the work, but generally speaking, separating operations from other product delivery work doesn't make sense. The only case where I can see it making sense is if you have an operations team that is supporting multiple products made by product delivery teams in production. Since multiple delivery pipelines are feeding into an operations structure, you may need to have a clear distinction between delivery and operations.
If you want to understand more about separating these activities, it's often referred to as "dual-track agile" (see 1, 2, 3). However, you won't see the separation of ops and product development, but more about the separation of different product discovery and ideation from the design and delivery components.