Will Software Eat Itself? How “product” and “skills” became a prefix for work that has always existed
The fourth in a series about the both/and scenario of designed operations and the intelligent use of people to design AI
Many roles are now “AI exposed” even though I, amongst other voices, see the changes differently and from a view of possibility and agency. I believe that design and other disciplines still have an important role in software and the development of artificial intelligence, and can help ‘make the world a better place’.
The beauty of hindsight
The title for this next article in this series is riffing off a band title, Pop Will Eat Itself.
Otherwise known as PWEI, PWEI were a band who I enjoyed in the 90s, giving away my age, no botox here. PWEI as they were otherwise known sounded cute, but evolved as artists in Thatcher’s Britain and mixed in political messages and witty commentaries on contemporary culture into their music and message, capturing a strong fanbase globally.
Like PWEI, SWEI, Software Will Eat Itself, also sounds cute, until you look under the hood.
Before I begin, I am relating opinions from my perspective and am more than happy to discuss this with you, dear reader, to add a touch of Bridgerton, should you wish to reach out.
I’d also like to add a disclaimer, this post isn’t anti-product. I have worked in product, strategy and design and research for most of my career. It’s a perspective on what has happened to design in the software industry.
My lens on the introduced SWEI problem
I am an experienced executive leader, consultant and adviser. I have served as a designer, educator, researcher, experience strategist, operations and change and transformation specialist. I have applied design and research in many multi-sector environments from SaaS to retail, education and financial services to the public sector, and have served as both a practitioner and capability leader in local and global product and technology teams or organisations.
Although trained as a designer and oriented in design and development since the beginning of my career in digital and software, and also, originally in fine art, I would also consider myself a product leader. I have since completed a Masters by Research in information systems and am currently on a break from a PhD investigating the design of AI and robotic systems through the lens of compassion, design and ethics.
I have served in product leadership teams and advised to executives in excess of two decades. A good portion of the research to strategy work I have directed, even in part, has informed a vision, roadmap and delivery pipeline, from opportunities and themes to initiatives to epic-level discovery or design sprints, and team-led execution.
Almost all of this work was human-centred and experience-led, using design research and mixed-methods research approaches. I have created opportunity sets, written jobs to be done, set prioritisation frameworks, sequenced and broken down initiatives, epics and user stories, sliced features, built capability and have been involved at every step of the strategy to delivery lifecycle. And although I have served in product leadership, I have never held a ‘product management’ job title.
Design, product and AI
In prior articles, I described how the design disciplines and sub-disciplines interact with current and new software such as forms of artificial intelligence (AI), from model decision making to making the outputs associated with machine learning, generative and agentic AI.
This article relates to the operating model I’ve designed which supports the design of safer AI software and relies on multi-disciplinary human involvement.
How it relates to this article
In this article I will discuss the workforce convergence and dilution of skillsets through the software industry’s power structures and use of automation. Part of this discussion will look honestly at how “product” or “skills” became a prefix for work that has always existed and must be human-originated. The disciplines I will focus on are design and product management, but I also consider other peer disciplines.
Introducing the product re-labelling and re-skilling problem
Open any software industry product job advert and you’ll find a set of terms presented as if they were invented inside the product discipline: product design, product delivery, product discovery, product strategy, product research, product marketing. Underneath these sits a second layer of frameworks and tools (e.g., product requirement documents, product evals, product roadmaps, product jobs, product taste, product sense) presented with the same tone of product-native invention.
While product management may have unique characteristics, not one of the aforementioned prefixed terms and it’s meaning is original or unique. Furthermore, not one of the frameworks or tools I mentioned are native to product management. The originating disciplines themselves still exist. Design, research, delivery, strategy, marketing, and engineering all continue to exist as independent disciplines and established, and diverse, professional fields, all with their own training, literature, and practitioners.
Why this product-prefix is happening, I believe, is not a natural evolution of discipline reinvention. “Product”, like “Technology”, is now a professionalised and centralised organisational power in software organisations. Product and technology organisations over the recent decade and a half, have become the common naming convention for two side by side organisational capability verticals in many of these companies. As with other disciplines, such as marketing, in many of these structures design has become a subordinate, often, in contemporary software, when embedded, a diluted discipline reporting into ‘Product’.
‘Product’ has since borrowed the methods of the aforesaid disciplines and reissued them under a ‘product’ label, often presenting them as though product invented them. However, the underlying practice, and often the practitioners themselves, whilst still evolving, still exist, often with deep valuable and relevant expertise. The label, however, and who now gets credited for it, has changed. And many folks outside of or new to software and artificial intelligence may not have a wiser understanding.
The implications of product prefixes are more than semantics. The impact of this seeming innocuous language and labelling shapes who gets hired, whose expertise counts as foundational rather than optional, who reports to whom, and increasingly, whose codified knowledge is available to be automated out from under them. A true rug pulling situation, and quite destablising for the many skilled professionals in software.
Furthermore, the frontier AI company and LLM marketing mandate of ‘abundance’, and ‘progress’, is in reality attempted industrial scale competitive automation of many already appropriated human roles. I believe this is a form of ‘workplace engineering’ which ultimately undermines diversity in organisations.
This is in fact a problem not only for these organisations but society as a whole. Many human workers in highly skilled professional fields, such as design, do not appear to be protected or redeployed, or furthermore, valued, in software. And a compounding factor is that when a company builds its whole structure around just two functions, “Product and Technology”, everything else (e.g., established professions including design, research, marketing, ethics, delivery, support) is pushed into a supporting, then automated or optional category by default.
It is truly ironic, that as a result, many organisations in software are now being criticised or even litigated against for poor design choices. Narrowing an organisation’s core to “product and technology” reduces diversity and who counts as core staff, which should raise alarm bells, not just about where good ideas come from, and also highlights a significant and critical risk, where investment is needed, who influences the way decisions are made and how these software solutions are designed.
Like ‘green washing’ and sustainability, I see this as the great “product and technology washing” of design and other professional disciplines in software. Software is eating itself. Not only am I wondering if this will be regulated and when this will stop, but consequentially, I am still attempting to understand why any of this is currently considered normal or ok.
The tale of two definitions
Design is a rich, diverse, and established field, built upon research-informed theory, philosophical debate, and the ‘shoulders of giants.’ When we look at how contemporary software professions have evolved, we see a stark contrast between established professional standards and modern practitioner definitions.
Consider the International Organisation for Standardisation (ISO) definition of Human-Centred Design:
Example 1: Human-centred design (HCD)
An approach to designing interactive systems that centres on the needs and characteristics of the people who’ll use them — applying human factors, ergonomics, and usability knowledge to make systems usable and useful, improve wellbeing and satisfaction, and reduce the risk of harm.
ISO 9241–210:2019, Ergonomics of human-system interaction — Human-centred design for interactive systems
Contrast this with the industry’s default definition of software Product Management:
Example 2: Product Management
The job of a product manager is to discover a product that is valuable, usable, and feasible.
Martin Eriksson
The irony here is significant. You may not be aware that the contemporary product mandate is lifted entirely from IDEO’s famous Three Lenses of Innovation. IDEO has practised human-centred design since 1978, and its co-founder, David Kelley, pioneered these concepts at Standford’s d.school, long before “product discovery” became a software buzzword. Similarly, the UK Design Council conceived the Double Diamond framework in 2004, now relabelled and modernised appropriately, mapping the systemic journey of discovering and defining problems before designing and delivering solutions.
By taking these holistic design frameworks grounded in the human experience and psychology, and compressing them into the transactional language of a product backlog, the software industry did not invent a new methodology. It merely appropriated an existing one, renamed it, and handed the driving wheel to a product manager.
This is not a sustainable model of behaviour. The software industry is expecting less human involvement through the development of skills and automation, and one person or a single role is responsible for much more decision responsibility than, often, their expertise supports. For people with less expertise, this makes enterpeneurship more accessible, which is at once positive, but the flipside is less so. These generative technologies and automations do not scale well, particularly with an exclusive ‘product’ lens, which I will explain further in this article.
While I am arguing that product managers are not designers, they are important stakeholders to a design decision. Unfortunately, the product operating model attempts to make other disciplines subordinate to product, instead of retaining discipline and peer autonomy, whilst sharing a common mission and mindset.
Notedly, this was one of the strengths of the Agile Manifesto.
The dilution of intent: ‘Product Jobs’ versus causal theory
This pattern of professional appropriation is starkly evident in the software industry’s treatment of Jobs-to-be-Done (JTBD). Originally developed through Clayton Christensen’s groundbreaking innovation research and published in The Innovator’s Solution (2003), JTBD was conceived as an application of the causal theory of human behaviour. JTBD theory sought to understand the deep emotional, social, and psychological reasons why a customer ‘hires’ a solution to make progress in a specific challenge.
Yet, within contemporary product practice, it appears that this expansive methodology has been thoroughly misunderstood. Enter “Product Jobs” or “Job Stories.” These are rigid, templated statements (“When I am in a certain situation, I want to perform an action, so I can achieve an outcome”), the framework has been conflated with standard Agile user stories.
What the modern product operating model labels as a “product job” is almost always a superficial task description, such as exporting a report or clicking a menu item, rather than the complex causal mechanism Christensen described. This semantic simplification strips the theory of its analytical substance, leaving behind a relatively hollow template.
The problem of the ‘product’ operating model
Now, product framing is landing software in hot water. The product operating model has become a dominant approach but this has resulted in a loss of discipline independence, skillset dilution, and reduction of diverse discipline autonomy. Further, I have noticed, people who work in ‘tech’, aka. software, forget that what they are designing and building are not always products.
This statement from Don Norman, expands the remit of design in the new software and frontier AI context, but is not holistic to all applications of design which I will next explain.
We are no longer designing products or interfaces; we are designing the systemic feedback loops that govern human behavior, resource distribution, and digital ethics. When you design a system of that scale, every pixel is a policy, and every algorithm is an environment.
— Don Norman
Let’s look at different kinds of applications of design in software and why the product lens is limiting.
Products
A product is a discrete, bounded, often narrow entity, designed to help a specific user or solve a problem in a transactional manner. Products are linked to revenue and short term optimisation. They are governed by tight feedback loops and business outcomes. Treating a whole system, platform or service like a product simply does not work.
Platforms
Platforms are not products, platforms are part of ecosystem building blocks. Platforms are infrastructure, that support multi-sided exchanges, and others to build, trade, create or connect. They provide the foundational architecture, protocols and standards to support diverse channel interactions, and ecosystem involvement. Platforms need to be built appropriately, with flexibility, stability and ergonomics. Platforms cannot be treated as a standalone application or optimised for feature output over structural stability.
Services
Services are not products that ship, rather, services evolve along a journey. Services are holistic, and end-to-end, with multiple touch points, people, actors and functions as well as interdependencies, and support complicated front stage to complex back stage orchestrations. Services are not just a digital interface, they are multi-layered, and matrixed. They cannot be built like a digital product, because they also incorporate operational workflows, however a digital product may or may not be a component of a service.
Systems
Systems are not products. They are interconnected and dynamic organisms. Systems are made up of a web of actors, structures, policies, and non-linear feedback loops. Systems can be complex and even chaotic. Where one lever is pulled, it may have predictable or unpredictable reverberations, results or consequences elsewhere in the system. Systems require evaluation, stewardship, continuous balancing and ethical principles, governance and forecasting, as well as monitoring. Narrow Language Models are complicated less complex systems. Frontier AI and Large Language Models are an example of a complex adaptive system.
I have not included other kinds of design here. Yes there are more, this is not an exhaustive list.
Now let’s look at the product prefix application.
Examples of the product prefix
Delivery compared to: Product Delivery
- Project and program management (e.g., planning, sequencing, and shipping work) has traditions going back to PMI and PRINCE2.
- Product delivery reframes standard delivery management as a “product” specialty; usually it’s delivery management now sitting under a product reporting line, not a new skill.
Design Thinking compared to: Product Discovery
- Design thinking is a human-centred design process popularised by the UK Design Council, IDEO and the Stanford d.school in the 2000s. It is a form of participatory design that emerged in Scandinavia in the 1970s. Design sprints were also popularised by Google Ventures and these incorporated frameworks like the Double Diamond and design thinking.
- Product discovery is Marty Cagan’s SVPG framing recasts the same diverge then converge process as a distinct “product” activity, separate from design.
Peer Functional Strategies compared to: Product Strategy
- Peer functional strategies (e.g., design strategy, engineering strategy, marketing strategy) belong to each function (e.g., design, engineering, marketing) and set their own strategy beneath overall business strategy. Design strategy directs craft and experience investment, engineering strategy directs technical architecture and platform investment, marketing strategy directs positioning and channel investment.
- Product strategy treated as senior to, rather than a peer of, the others in product and technology businesses. It becomes a parent strategy and a dependency.
Research compared to: Product Research
- Research, including market research, ethnography, human factors, commercial and academic disciplines with twentieth-century roots.
- Product research and UX research splits general research practice into product-specific labels, often carried out by researchers trained in the original, broader discipline but often reduced to product manager-led customer discovery sessions or synthetic AI research.
Marketing compared to: Product Marketing
- Positioning, messaging, segmentation, go-to-market have been formalised in marketing theory since Kotler and mid-century marketing practice.
- Product marketing reduces general marketing craft to a single product line; segmentation, messaging frameworks, and launch sequencing are inherited directly from classical marketing, not newly developed in product teams.
Software Engineering compared to: Product Engineering
- Computer science and software engineering (e.g., architecture, systems design, implementation) has a decades-old professional and academic lineage.
- Product engineering reframes engineers on product teams as accountable for product outcomes rather than technical specification alone, however prior to this framing, UX and design did this as part of the system of work.
The same pattern of unattributed borrowing of existing frameworks and tools applies, and it’s worth separating them out as implementation-level tools rather than discipline equivalents.
Get Catherine Hills’s stories in your inbox
Join Medium for free to get updates from this writer.
Evaluation Research and Testing compared to: Product Evals
- Evaluation research and usability testing (HCI, statistics, 1980s-90s); in AI specifically, systematic model performance testing draws on ML evaluation methodology.
- Evals is product language for user testing and validation, or AI model performance testing. It is an implementation method drawn from evaluation research, not a discipline in its own right.
Business Analysis and Requirements Engineering compared to: Product Requirements Document (PRD)
- Requirements engineering and business analysis – specifying functional and non-functional requirements, formalised in software engineering since the 1970s-80s.
- PRDs are emerging as standard artefact for scoping a feature: goals, user stories, acceptance criteria. The same discipline business analysts and systems engineers already practised, now scoped to a single feature.
Opportunity Spaces compared to: Opportunity Solution Trees also named Product Opportunity Trees
- “How Might We” ideation statements, a technique from design thinking traced back to Procter & Gamble in the 1970s and popularised by IDEO.
- Opportunity Solution Trees were pioneered by Teresa Torres to structure product discovery work. The tree organises discovery by placing an outcome at the top, which branches down into the opportunity space (customer pain points), followed by solutions and experiments. Torres’s framework deserves credit as a highly effective, product-specific synthesis; it bridges traditional design thinking techniques with continuous product execution. Often, however, in product circles the design thinking background is not acknowledged.
Visual and Brand Design compared to Product Taste or Product Sense
- Visual and brand design craft (typography, composition, brand systems) plus qualitative research judgement – trained skills with their own teaching and critique traditions.
- Framed as an individual, near-innate instinct held by strong product leaders e.g., “good taste,” “sharp product sense.” Repackages trained aesthetic and research judgement as personal intuition, detaching it from design and research expertise. Problematic, because instinct can’t be credentialled or questioned, and reduces the value of a design or research qualification that in fact builds intuition through expertise.
Jobs to be done (JTBD) and Agile User Stories compared Product Jobs
- Clayton Christensen’s innovation research (developed with Anthony Ulwick, formalised in The Innovator’s Solution, 2003) is a causal theory of why customers hire a product to make progress in a specific situation.
- Commonly reduced in product practice to “product jobs” or job stories – templated statements (“when I ___, I want to ___, so I can ___”) that are really just user tasks. This is a watered-down version of Christensen’s theory, conflated with user stories not an application of it. What’s called a “job” in most product usage is a task description, not the causal mechanism Christensen described. The simplification strips out the theory’s substance while keeping its name and borrowed authority.
An anecdote:
A half-day of research training doesn’t make anyone a research expert, any more than a half-day of design training makes someone a designer, marketer or a product manager. The relabelling with a product prefix doesn’t just rename research, it minimises the training and expertise required to be an expert researcher, because “product research” implies a skill any PM can pick up as a side competency. “Research” as a standalone discipline requires years of methodical academic training.
The colonisation of context
The strategic flattening of adjacent disciplines into product-prefixed roles can be viewed as an active colonisation of organisational context. Driven by the deliberate “workforce engineering” of tech organisations, this architecture creates a semantic environment where every architectural asset, human interaction, and feedback loop is reclassified as “product-owned.”
Through this mechanism, the product operating model successfully establishes a singular hierarchy of ownership and governance, resulting in the systemic dissolution of surrounding professions. This positioning frames the product arm of a software enterprise as the ultimate arbiter of value, rendering mature disciplines outside of product — for now — as inappropriately subservient to a singular mandate.
Within the design realm, this dynamic reduces the design practitioner to isolated, pixel-production decision-making, severely diluting the strategic decision making input an experienced designer can make, even though interaction and visual design are nuanced and important sub-disciplines. It also reduces the scope of the design capability. And while product managers are not designers, the foundational models popularised by Eriksson and Cagan may have been weaponised to absorb and dilute the contributions of independent disciplines.
Furthermore, by aggressively cutting resources and absorbing external frameworks, methods, and skillsets into a single product management umbrella, organisations create a “totalisation” effect. This engineering of a single-prefixed overarching “product” discipline yields dangerous consequences, laying the groundwork for a hollowed-out “skills creation” paradigm designed to automate the very professional contributions it has just finished incorporating.
The counter view: a natural evolution in software?
Natural field evolution has a recognisable pattern in that new terms emerge to name genuinely new practice, credit tends to flow towards whoever did the original work, and the exchange runs in more than one direction over time.
What’s described above doesn’t consistently have that shape. The direction is one-way (e.g., design, research, delivery, marketing, engineering, and business analysis) have all in some way shape or form been renamed into product. Product terminology hasn’t, yet, over the same period, been absorbed back into those fields.
The renaming demonstrates changes in organisational power (e.g., product’s control of roadmaps, budget, and headcount) rather than where underlying innovation happened. Again, think Christensen’s Jobs to be Done research and IDEO’s Three Lenses of Innovation predate their “product” versions, sometimes by decades.
However, the practitioners doing the work are still, but often less so, the same people who did it under the original name. Sadly, in software, this has had a consistent effect: whoever controls the relabelling gets to write the canon, run the organisation, and define seniority, while the discipline being absorbed has to argue and advocate for the recognition of expertise it already had and still maintains in the rest of the world.
Codification exposure
This intentional hollowing of discipline autonomy reaches its logical conclusion in the current wave of algorithmic automation. I would like to call out that this playbook is cyclical and unpleasant: first, the product operating model isolates a complex, highly specialised discipline, such as design, qualitative user research, or technical delivery, and strips away its strategic, systemic dimensions. In the case of design, it forces a rich, human-centred, philosophical and technical practice into a hyper-localised, mechanical execution layer.
Many design leaders have commented on this risk: design, instead of evolving its remit and application more fully, which as a discipline design is naturally attuned to, desgin is reduced to automating its own reduced application. This might show up as less design and more selection, whcih moves design from design to taste (e.g., selecting UI components from a pre-baked Figma library). This devolves the design capability to less design and more production ‘upskilling.’ It also results in design becoming competitive with peer disciplines such as product (e.g., when a product manager or another colleague uses a generative AI design tool incorporating that very library’s codified knowledge). Research is flattened (e.g., via skills based rules, running rapid, binary user-testing scripts or prompts). The shift here is also interesting, in that in the past for design tooling, often the most sophisticated yet usable tool was the preferred one, now the bias has shifted to fast output over human design origination or involvement. This is an analogy for most professions where skills are watered down — the very skills spent years crafting and developing ‘intuition’ around.
By reducing these holistic disciplines such as design to a repetitive, assembly-line cadence, the product ecosystem successfully manufactures a false perception that these roles are merely mechanical, low-leverage execution tasks. And it limits the potential not just of individuals in professional roles, but possible outcomes they drive and potential of the outputs they create. For example, the process of ideation or design, also, often requires drawing and pen and paper thinking. Multiple studies have demonstrated this improves creativity, learning and innovation potential. Yet the common belief, while I do support the inclusion of ideas coming from many sources, is that generative AI tooling and automation will amplify creativity.
Once a discipline, such as design, has been thoroughly diluted and commoditised in this manner, it is ripe for structural elimination. Organisations are actively utilising this artificial simplicity to justify the creation of automated “skills” engines. By feeding these narrow, stripped-down tasks into generative AI pipelines and automated workflow templates, companies claim they can bypass the need for experienced practitioners entirely. A product manager, armed with an AI copilot, is told they can now generate prototypes or synthesise research independently.
This is the ultimate danger of the “totalisation” effect: it creates an echo chamber of engineered mediocrity. It replaces deep ethical forecasting, relational empathy, and structural systems design with a frictionless pipeline of automated outputs. The software organisation celebrates the immediate speed of these automated inputs, remaining entirely blind to the fact that they have systematically eradicated the very human expertise required to prevent architectural debt and societal harm.
Tacit, uncodified expertise is valuable, and organisations are at risk of forgetting this.
I’d like to reiterate that designers who build software and artificial intelligence systems are doing genuinely valuable work. However turning tacit expertise ( human-input, rules, ethics, values, patterns, decision-making, inclusive design) into not only usable solutions but systems design has consequences. Codifying expertise also makes it transferable in a new way. If design is however reduced to pixel selection, this is different. This is why many a design leader and influential professional figure is lamenting the reduction of design to visual design only, even though visual design is critically important!
This is given once a design system or pattern library exists as a structured, documented asset, it becomes exactly the kind of thing that can be packaged into an automation tool that runs against it without needing the person who built the judgement behind it. It is different when designers own these systems. They can evolve them. However that means evolution and decision making is difficult to manage and articulate and as I’ve said in multiple commentaries, that needs to be design and human led, and design governed, because designers have the expertise to do so. Perhaps in partnership with engineers. And of course as this kind of tool has become an enabling service to the entire product and technology organisation, then a product manager.
However, the organisation believes now they have a system, like a design system, the buck stops there. That is because the reductive mental model of design is the pixel creation. And then the automation and production through generative AI. The irony is that other disciplines, including product or technology people, face the same exposure from the artefacts they’ve been busy relabelling as their own.
Code standards, code snippets, components, product requirement document templates, product discovery playbooks, product prioritisation frameworks, product opportunity trees. Writing these down and standardising them is good practice. But automation hides the skills, makes them less teachable to a machine or learnable for a junior hire. Tacit, uncodified expertise is valuable for many reasons, and organisations are at risk of forgetting this.
Safety, and conduct, first
Designers, nor other established professions, should not be made redundant, or indeed “product and technology” or “AI” “washed” they should evolve. Judgement, testing assumptions, and navigating messy stakeholder situations, and wicked problems, involving tacit information sharing and relational exchanges, all central to design work, aren’t reducible to a codified artefact.
It’s worth being again reflective here, the very act of packaging expertise into frameworks and documentation, the thing both product and design, as well as engineering, disciplines in software have spent the last decade doing as part of best practices in record keeping, to be more “scalable”, is also what leaves that expertise most exposed to automation.
‘Product’ isn’t exempt from the automation. Without a promotion of diverse disciplines, it seems that the race to be the ‘last person standing’ is really shortchanging the next generation of software technologists who might be interested in design or product or indeed other evolving sub-disciplines emerging from these professions.
The prefix, absorption and appropriation behaviour, reducing designer headcount in software, disadvantages design and indeed the organisations this is occurring in. It diminishes the potential of great design to happen, and that shortchanges a duty of care in software and reduces the potential for multidisciplinary teams to develop real solutions that enable human flourishing.
As I reminded readers in my prior article, “How to Check Your AI system Still Matches Your Values”, the software industry and businesses have the opportunity to do this differently. As mentioned in the prior article, HCAI or HAI is:
An approach to AI that prioritizes human needs, values, and well-being throughout the development and deployment of AI systems. HAI prioritizes collaboration between humans and machines, ensuring that technology is developed with empathy, ethics, and user experience in mind. HAI integrates insights from fields like computer science, psychology, ethics, and design to build systems that are trustworthy, inclusive, and aligned with societal goals. — Standford University HAI
I’d also like to emphasise – this article is not about accusing product management of being ‘meanies’ or claiming ill intent towards any individual product leader. However, my intention is to speak truthfully about a single-directional, power-tracking, credit-erasing pattern. This pattern is a different thing from disciplines genuinely converging and cross-pollinating.
It’s worth paying attention to this now, rather than defaulting to “evolution,” which actually, is professional gaslighting. None of this is saying product management as a role is not relevant or valuable, or that genuine new practice can come from it, particularly around prioritisation at scale and cross-functional alignment to value. However, what value is that? That is what I’m querying here.
In this world of generative tooling, the control around what is automated and what should not be automated should be controlled by the profession that invented it.
What we need to think about
My argument is that when a term, framework, or skill gets a “product” label, or another, it’s worth asking whether something new was created, or whether an existing discipline’s practice, tools, and people were absorbed and their origins removed and the lineage of knowledge broken. This matters for hiring, for career fairness, for who’s left exposed when codified expertise gets automated, and for the profession and software industry’s professional integrity.
The solution is not by naming the design, research, strategy, delivery, and business-analysis professions with a ‘product’ prefix. Or indeed potentially automating a skill. In this world of generative tooling, I believe the control around what is automated and what should not be automated should be controlled by the profession that invented it. The solution is to be responsible and credit the practitioners who built that expertise and the frameworks, and honour their skills and experience.
There is a real dilemma when the workforce or the profession does not feel in control of their outcomes. Conduct is important and that also relates to internal systems change and workforce transformation. Many people I speak with lament the ‘world of work’ we are in. Core values such as dignity, respect and autonomy deserve attention.
The end of the assembly line: reclaim the discipline? Or accept the changes?
When I look beneath the veneer of the “product operating model”, I find that its ultimate consequence is an acute vulnerability to the very automation the ‘software’ and ‘AI’ tech industry now mandates, and diminishing towards the very professions and colleagues that were so great to start with. It’s worth sitting with.
By stripping design, research, and delivery of their respective professional discipline’s autonomy, reducing them to a series of prefixed tasks like “product discovery” or “product taste” in pixel production, the software industry has accidentally tripped itself up.
Ultimately, it may not matter if it design shows up as ‘product’ or not, but it will matter if expertise is undone. The software industry has diluted deeply creative, ethically matrixed human practices into rigid, predictable assembly lines. Furthermore, if a job has been engineered to look like a predictable assembly line, it becomes remarkably easy to convince an executive that an LLM can do it for a fraction of the cost.
This is the reality of the frontier AI “abundance” narrative. It is the industrial-scale human-competitive automation of roles that are becoming deliberately diluted ahead of time. When companies claim that product managers or other roles equipped with generative AI can now independently run research synthesis or generate user interfaces, they are celebrating an echo chamber of engineered mediocrity.
A narrow language model can mimic a standardised product template, but it cannot exercise ethical forecasting. A large language model cannot navigate a chaotic social ecosystem. It cannot hold space for the complex, matrixed human interdependencies that define a true service or system. However, both NLMs and LLMs have their uses. The designed intent is what drives better outcomes.
Despite the potential possibilities or degradation of design and other professional disciplines, we must stop pretending that this “product and technology” or “AI” “washing” of established professions is a normal or healthy evolution. The dilution of important, nuanced skillsets is a critical risk to innovation, a degradation of organisational diversity, and a direct threat to the safety of our shared digital environment.
It is time to look beyond the bounded limits of the product operating model and remember what we actually do: we design the systemic feedback loops, the relational journeys, and the architectural foundations of our world.
To the designers, researchers, and specialists who feel “AI exposed” under this unfortunate mandate, the path forward is not to become better cogs in the machine. The path forward is to assertively reclaim our discipline autonomy, even if it has been renamed ‘product’ or downplayed as an AI ‘skill’. We must stop letting our discipline be colonised by a transactional vocabulary.
It is time to look beyond the bounded limits of the product operating model and remember what we actually do: we design the systemic feedback loops, the relational journeys, and the architectural foundations of our world.
I would also like to say that designers, and anyone who conducts design, have a responsibility to evolve too. It is not enough to sit on our laurels and rely on synthetic research or the AI rendering of an interface, without the thinking first. Not all ‘design’ is suitable for software, and designers need to learn the context to apply their discipline to it.
This does not mean the tools or replicable methods and frameworks take over, this means revisiting what design is, and undertaking appropriate research and speaking with people to meet HCD ISO and HAI standards in software.
I’ve worked with many fantastic product partners who understand the value of design. However, because of said practitioner influencers, many product managers opt for the “CEO of the product” mindset, as endorsed by many product thought leaders. Product managers are not always designers, and if product management went back to its roots it may more healthily and sustainably evolve the role into something that makes sense, is sustainable and uniquely valuable in software.
Furthermore, designers, researchers and indeed other professions who interact with software must enact change, either in themselves by considering the stay or go question, or by taking control moving forward in situ or in a different direction.
It is incredibly difficult to change the status quo in existing organisations without forward-thinking boards or executive investment, however, demanding honesty is a great start.
There is the value of our established professions to lean on. Acting with agency, means looking forward to where we wish the design profession, and related professions must arrive in the future.
In conclusion, ask yourself this: What makes a great professional partnership and journey, and is that being realised with the company, and colleagues you work with, or with the AI services you use as execution partners or copilots?
