I recently heard the head of Claude Code talk about the different roles he is starting to see emerge in software teams.
The prototyper. The builder. The maintainer. The scaler. The janitor/polisher.
It made a lot of sense to me, especially because I've been exploring new ways of building products with AI and reflecting on how teams work at different stages of the product lifecycle.
But the more I thought about it, the less I saw them as fixed roles.
I started seeing them as modes.
A person might naturally be better at one of them, and larger companies might hire people specifically for each role. But when you are working solo, in a small team, or inside a large enterprise, you are constantly moving between all of them.
The product changes, and your focus needs to change with it.
For me, the five modes are:
Explore
This is where an idea starts becoming something real.
You create a rough interface. You connect the main screens. You try different flows. You make the experience tangible enough that someone can understand it and react to it.
The goal is not to build the final product.
The goal is to learn.
Does the idea make sense?
Can it be built?
Would someone actually use it?
Is the experience clear?
This mode is about reducing uncertainty as quickly as possible.
AI has made this part of the process much faster. One person can move from a thought to something interactive in a very short amount of time.
What is also changing is the quality of the prototype itself.
We are no longer limited to static screens or fake interactions. We can now explore ideas using real code, real interfaces, real data, and experiences that are much closer to the final product.
That makes the learning more useful.
People can interact with something that behaves like the real product instead of imagining how it might work from a presentation or a design file.
This matters regardless of the size of the company.
For a solo builder, exploring first can prevent weeks of building the wrong thing.
For a small team, it can create alignment before too much time and money are invested.
For an enterprise, it can reduce uncertainty across design, technology, compliance, operations, and business teams before a large delivery begins.
Exploring with real experiences can reveal usability problems, technical limitations, confusing flows, missing requirements, and unexpected user behaviour much earlier.
That does not mean every issue disappears.
It means many of the expensive issues can be discovered while they are still small.
A confusing experience found during exploration might take an hour to change.
The same problem found after launch might require design changes, code changes, data migrations, testing, training, support, and communication across multiple teams.
Exploration is not just a creative exercise.
It is a way to reduce risk.
Build
Once the idea starts making sense, the focus changes.
Now you need to create something people can actually use.
This means making decisions about the structure of the product, the technology, the data, the experience, and all the small things that a quick exploration can ignore.
The building mode takes what was learned during exploration and turns it into the first real version.
This is also where the tradeoffs become clearer.
What needs to be included now?
What can wait?
What is solid enough to release?
The purpose is no longer just learning.
The purpose is shipping.
Because the team has already explored the experience using something tangible, the build can begin with a much clearer understanding of what needs to exist.
That clarity does not remove complexity, but it can reduce avoidable rework, unclear requirements, broken assumptions, and unnecessary features.
Evolve
After releasing a product, the work does not stop.
Users find problems. Platforms change. Dependencies need updates. Features need adjustments. Some ideas work differently in the real world than they did during exploration.
Evolve feels more accurate to me than maintain.
Maintenance can sound like simply keeping the product alive.
Evolution is more active.
You are looking after the product, but you are also helping it adapt.
You are fixing what is broken, improving what already exists, responding to feedback, removing what no longer works, and making sure the product continues to be useful.
This mode may be less visible than launching something new, but it is what allows a product to remain relevant.
A healthy product is never truly finished.
It keeps changing as the people using it, the technology around it, and the business behind it change.
Grow
At some point, the main challenge is no longer building the product.
The challenge is getting it in front of more people.
This mode is about growth.
It could mean improving onboarding, trying a different pricing model, creating specific features for a new audience, entering another market, or finding better ways to explain the value of the product.
It is not only marketing.
Growth can come from the product itself.
A feature might make it easier to share. A better first experience might help more people understand the value. A change in positioning might attract a completely different audience.
For a larger organisation, growth might mean supporting more customers, more regions, more teams, more data, or more complex use cases.
The question becomes less about whether the product works and more about how it can reach ten times or one hundred times more people without losing what made it valuable in the first place.
Delight
This is the mode that focuses on how the product feels.
The little details.
The transitions.
The language.
The moments of clarity.
The places where someone understands what to do without needing to think about it.
Delight is not about adding decoration or making everything animated.
It is about making the experience feel considered.
It is about removing friction, creating confidence, and finding the moments where the product can feel more human.
The product might already work.
It might already be stable.
It might already be growing.
But delight can turn something functional into something people genuinely enjoy using.
Sometimes delight is a beautiful interaction.
Sometimes it is a thoughtful message.
Sometimes it is simply making something easier than the user expected.
These are not fixed roles
What I find interesting is that a product does not move through these modes only once.
A new feature might begin in Explore, move into Build, continue through Evolve, become part of a Grow strategy, and eventually receive more attention in Delight.
Then new feedback, technology, or business needs might send it back to Explore again.
This is not a straight line.
It is a cycle.
This is especially noticeable when working solo.
On one day, I might be testing an idea and creating a rough flow.
The next day, I am deep in the code trying to make it work properly.
Later, I am fixing bugs, improving existing features, thinking about how people will discover the product, or adjusting a small interaction because it does not feel quite right.
I am not changing jobs every day.
I am changing modes.
The same idea applies inside a company.
A small team may have the same people moving between every mode.
A larger organisation may have different teams responsible for each one.
An enterprise may have hundreds of people contributing across all five.
The size of the company changes who does the work.
It does not remove the need for any of the modes.
In fact, the larger the organisation, the more valuable early exploration can become.
More people, systems, approvals, and dependencies mean that mistakes become more expensive as the work progresses.
Using real code and real experiences early can create shared understanding before the organisation commits to the full build.
It gives designers, engineers, product teams, business stakeholders, and users something concrete to react to.
It can expose issues before they become delivery problems.
That is probably one of the biggest changes AI is enabling.
It is becoming easier to move from an idea to something real enough to test.
Not just a presentation.
Not just a document.
Not just a collection of screens.
An actual experience.
The important skill might not be mastering one mode forever.
It might be understanding which mode the product needs from you right now.