As the boundaries between engineering, product, design, and data science become thinner, teams may stop organizing work around job titles and start organizing around the kind of value needed at each stage: prototypers, builders, sweepers, growers, and maintainers.
I recently saw an interesting tweet: as engineering, product, design, data science, and other functions begin to merge into more hybrid roles, will future teams stop defining people by job titles and instead define them by how they create value?
Using the Claude Code team as an example, the tweet abstracts contributors in a product team into five archetypes:
- Prototyper: proposes new ideas and quickly creates many prototypes, most of which will never ship.
- Builder: turns prototypes or ideas into production-grade products and infrastructure.
- Sweeper: polishes UI, simplifies code and systems, removes unnecessary features, and improves performance.
- Grower: iterates after the product exists and pushes it toward product-market fit.
- Maintainer: owns the safety, reliability, speed, and cost efficiency of mature systems so they can operate at scale.
The important point is not the labels themselves. It is the organizational lens behind them: in the AI era, product teams may rely less on “you are an engineer, designer, PM, or data scientist” and more on “what kind of problem do you mainly solve in the product lifecycle?”
Functional Boundaries Are Getting Thinner
Traditional product teams often looked like an assembly line.
PMs wrote requirements, designers produced mockups, engineers implemented them, data analysts watched metrics, and QA or operations protected quality. Everyone had clear boundaries and relatively fixed deliverables.
AI tools are thinning those boundaries.
An engineer can use models to quickly produce usable interaction prototypes. A designer can generate frontend code from natural language. A PM can ask an agent to pull data, write SQL, and classify user feedback. A data scientist can turn analysis results directly into interactive product experiments.
This does not mean everyone becomes the same kind of “all-purpose person.” More accurately, when job boundaries weaken, the real capability structure a team needs becomes more visible.
What is scarce is no longer a specific title. It is a stage-specific kind of value:
- Someone can keep opening possibilities.
- Someone can turn possibilities into shippable systems.
- Someone can clean complex systems back into shape.
- Someone can move the product closer to the market.
- Someone can keep a successful system running reliably over time.
That is the real value of the five-archetype model.
1. Prototypers Open Possibility
A prototyper’s job is not to prove every idea is right. It is to expand the exploration space at low cost.
In early products, the most dangerous mistake is often not being wrong, but converging too early. Teams may stop at the first reasonable-looking solution and spend a large amount of engineering effort on a direction that has not really been validated.
The value of a prototyper is to continuously create things that can be discussed, tried, and rejected.
They may build three or four demos in a day, sketch immature interactions, or write experimental code that is not meant to be maintained long term. Many outputs will never ship, but that is not waste. When uncertainty is high, eliminating wrong directions quickly is progress.
AI amplifies this role. What once required waiting for design, frontend, and backend work can now be turned into something tangible much faster by someone skilled with AI tools.
But prototypers also have a natural risk: they can become attached to novelty, avoid convergence, and keep opening new threads without closing them. A team made only of prototypers will feel lively but may struggle to produce a real product.
2. Builders Turn Prototypes Into Products
Builders care about a different question: can this actually be delivered to users?
There is a deep gap between demo and production. A prototype can use manual data, skip error paths, and serve one ideal user. A production product must handle permissions, failures, performance, monitoring, deployment, compatibility, data consistency, and many edge cases.
The builder’s value is turning “looks usable” into “actually usable.”
These people are usually good at balancing speed and quality. They do not slow everything down for perfect architecture, but they also do not disguise throwaway scripts as long-term systems. They know what can be simplified temporarily and what must be done carefully from day one.
Builders become even more important in the AI era. As prototype creation speeds up, teams will produce more half-finished ideas. The scarce skill is not making yet another demo, but deciding which demo deserves to become a product and landing it steadily in the real system.
3. Sweepers Reduce Complexity
Sweepers are one of the most underestimated roles in many teams.
They may not always build the most visible new feature, but they often determine whether a product can keep moving fast. Any product that keeps iterating accumulates complexity: unused features, duplicate components, tangled state, historical baggage, performance debt, copy debt, and interaction debt.
Complexity does not disappear by itself. It taxes every future requirement.
Sweepers do work such as:
- Simplifying an overdesigned flow.
- Removing a feature no one uses.
- Merging duplicate code paths.
- Clarifying messy UI states.
- Improving performance so the system feels light again.
- Redrawing module boundaries to lower future development cost.
This work is not always immediately captured by metrics, but it changes the team’s velocity curve. Without sweepers, the early speed advantage of a product is gradually eaten by complexity.
As AI coding becomes common, sweepers become even more important. AI can generate code quickly, but it can also expand code volume quickly. Generation is not the finish line. Organization is what makes a system usable over time.
4. Growers Move the Product Toward the Market
Once a product works, the problem changes.
Early teams ask, “Can we build this?” Growth-stage teams ask, “Why do users not use it more often? Why is conversion not happening? Why is retention weak? Why is the value real but not felt?”
The grower’s core skill is connecting product, users, channels, and data.
They are not just growth hackers chasing short-term tricks, nor are they only staring at dashboards. They find friction in user behavior, extract real needs from feedback, locate problems in funnels, and drive product iteration.
Growers often cross several traditional functions: product judgment, data analysis, user communication, and enough understanding of implementation cost. They may not write all the code themselves, but they must be able to turn vague growth problems into testable experiments.
If prototypers open possibility and builders deliver it, growers decide whether the product has entered a real market loop.
5. Maintainers Make Success Sustainable
Maintainers often become visible after a product is relatively mature.
When a system carries real users, revenue, and business processes, the goal is no longer only to ship new things faster. It also includes: do not break, do not slow down, do not leak, do not lose control, and do not become too expensive to sustain.
Maintainers care about the long-term quality of mature systems:
- Security: permissions, data, dependencies, supply-chain risk.
- Reliability: recovery, observability, capacity planning.
- Performance: latency, resource usage, critical path optimization.
- Efficiency: cost, automation, internal tools, operations workflows.
- Evolution: upgrading without breaking existing user experience.
If a team enters maintainer mode too early, it may become conservative. But if a product with strong PMF lacks maintainers, early success can turn into technical and organizational burden at scale.
Maintenance is not the end of creation. It is what allows created things to continue existing.
Different Stages Need Different Mixes
The most useful part of this model is that it helps a team understand what it lacks at the current stage.
If the product is new and has not found PMF, the team needs prototypers, builders, and sweepers. The focus is fast exploration, fast delivery, and fast cleanup so early chaos does not slow later progress.
If the product has started growing and has early PMF, the team needs more builders, sweepers, and growers, while introducing some maintainers. The team must keep improving the product, optimize experience and conversion, and prepare for scale.
If the product already has strong PMF, the center of gravity shifts toward sweepers, growers, and maintainers, while keeping some builders. Adding more prototypes and features may not be the highest return; improving system quality, expanding market coverage, and reducing long-term complexity may matter more.
This also explains why the same person can have different value at different stages. A brilliant early prototyper may feel constrained in a mature product. A strong maintainer placed into a still-uncertain early product may make the system too heavy. The issue is not always capability. It may be mismatch between role and stage.
Roles Are Contribution Modes, Not Job Titles
This model has another important insight: these roles are not tied to traditional functions.
Some designers are classic prototypers, quickly producing many new interactions. Others are sweepers, excellent at simplifying complex flows. Some engineers are builders who stabilize systems quickly. Others are maintainers focused on reliability, security, and performance. Some PMs are growers; others are closer to prototypers.
One person does not have to belong to only one role. Many people span two, and some span three.
But few people are equally strong across all stages. What team leaders should look at is not whether every function box exists on an org chart, but whether the current product stage has the contribution modes it needs.
This affects hiring, performance evaluation, and collaboration.
When hiring, the question should not only be “do we need another frontend engineer?” or “do we need another PM?” It should also be “do we lack someone who explores direction, productizes ideas, or cleans up complexity?”
When evaluating people, one standard should not be forced onto everyone. A prototyper’s value may be exploration volume and insight quality; a builder’s value may be delivery speed and production quality; a sweeper’s value may be reduced complexity; a grower’s value may be movement toward PMF; a maintainer’s value may be long-term stability and efficiency.
When collaborating, avoid having everyone crowd into the same role. A team of only prototypers floats. A team of only maintainers slows down. A team without sweepers gets heavier and heavier. A team without growers may build something good and still fail to find the market.
Personal Takeaway: Define Your Main Value, Not Only Your Title
For individuals, this model is also useful.
AI is lowering the barrier for many concrete skills. Knowing a bit of coding, design, and data analysis will become increasingly common. The more important question is: at which stage do you create irreplaceable value?
Are you good at going from 0 to 0.1, turning vague ideas into prototypes?
Are you good at going from 0.1 to 1, turning prototypes into shippable products?
Are you good at going from chaos to clarity, reorganizing complex systems?
Are you good at going from 1 to 10, driving growth through users, data, and experiments?
Are you good at going from 10 to 100, helping mature systems scale reliably and efficiently?
This question is closer to the future of work than “am I an engineer or a product manager?”
As tools become stronger and functional boundaries become thinner, what distinguishes people is no longer just which tool they know. It is what responsibility they can reliably carry through the uncertainty of a product lifecycle.
Closing
Future product teams may not eliminate job titles like engineering, product, design, and data. But those labels may matter less.
What matters more is whether a team can assemble the right role structure at each stage: someone explores, someone builds, someone cleans, someone grows, and someone maintains.
The value of the five-archetype model is not to create new titles. It reminds us that products do not grow from functional org charts. They grow through a relay of different kinds of value.
When AI flattens tool capabilities, the thing worth rethinking is how we define people, teams, and the full set of forces needed to take an idea to maturity.
