Construir o futuro sem parar a plataforma

How do you radically evolve a product without neglecting the platform customers already depend on?

In 2016, I was working at Take Blip as both a Manager and Developer, leading two engineering squads.

One of them was responsible for our own OTT messaging application. As the messaging market changed and platforms such as WhatsApp opened new opportunities for businesses, that product was eventually discontinued.

The other team worked on MensagemHub, the platform that would later evolve into BLiP.

At the time, I was still very close to engineering. I wasn't managing development from a distance. I was writing software as well — during this period, for example, I developed the first version of what became BLiP Chat.

Then our Product Manager left, and I also took on the product responsibilities.

That put me in an unusual position.

I was working across product management, engineering management and software development at the same time. I was responsible for the roadmap and product direction, but I was also close enough to the engineering work to understand the operational constraints behind that roadmap.

And we were about to make a significant change to the product.

MensagemHub was evolving from a messaging platform into BLiP: a SaaS product where companies could build and operate their own chatbots.

We needed to move quickly.

But we couldn't stop everything else while doing it.

---

We needed to rebuild the product without stopping the product

The transformation into BLiP required much more than a sequence of small improvements.

We needed to build new capabilities and make structural changes to the platform.

At the same time, the existing product was already running.

Customers were using it.

Bugs still happened.

Incidents still happened.

Support requests, operational issues and smaller improvements didn't disappear just because we had a more ambitious roadmap.

So we effectively had two products competing for the same engineering capacity:

THE PRODUCT TODAY
─────────────────
Bugs
Incidents
Support
Operations
Small improvements

        vs.

THE PRODUCT WE WANTED TO BUILD
───────────────────────────────
New capabilities
Structural changes
New product experiences
The evolution from MensagemHub to BLiP

There was also a third dimension that was just as important: the team.

Engineers wanted to participate in the transformation.

Nobody wanted to spend month after month exclusively fixing bugs and handling operational work while another group got to build everything new.

That made what initially looked like a prioritization problem into an organizational design problem.

The question became:

How could we create enough focus to evolve the product quickly, continue operating the existing platform, and give different people the opportunity to participate in building its future?

---

The obvious solution had a people problem

One obvious approach would have been to divide engineering permanently.

One team could focus on innovation.

Another could maintain the existing platform.

From a capacity-planning perspective, that sounds reasonable.

But I didn't like what it could create over time.

We could easily end up with an implicit hierarchy:

Team A → builds the future

Team B → maintains the past

The first team would continuously work on greenfield problems, new architecture and visible product initiatives.

The second would receive bugs, incidents, support requests and technical debt.

Even if both teams were equally important to the business, they wouldn't necessarily feel equally important to the people doing the work.

There was another problem.

Knowledge about the new platform would gradually become concentrated in the "innovation team."

The more successful that team became, the more dependent we would become on the same people.

I wanted focus, but I didn't want permanent ownership of innovation.

That distinction became the foundation of the model we eventually adopted.

---

Focus Teams

I designed a structure based on temporary teams that we called Focus Teams, working in parallel with a Core Team.

A Focus Team wasn't a permanent squad.

It was created to solve a meaningful product problem and existed for approximately two months.

After that, it disappeared.

Its members returned to the Core Team, and a new Focus Team was assembled for the next problem.

The basic cycle looked like this:

                 PRODUCT PROBLEM
                        ↓
                   FOCUS TEAM
                        ↓
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
      DISCOVERY        BUILD       STABILIZE
       2 weeks        1 month       2 weeks
          └─────────────┼─────────────┘
                        ↓
               KNOWLEDGE SHARING
                        ↓
                    CORE TEAM
                        ↓
                NEXT FOCUS TEAM

Meanwhile, another flow continued in parallel:

CORE TEAM
    ↓
  KANBAN
    ↓
BUGS / INCIDENTS / SUPPORT
SMALL IMPROVEMENTS / OPERATIONS

The important part wasn't the terminology.

We weren't trying to invent a new agile methodology.

We were trying to create an operating model that reflected the reality of the product.

---

Two months to solve a meaningful problem

A Focus Team typically had around two months.

That timebox was deliberate.

Without a constraint, an important initiative can easily become an endless project.

There is always another architectural improvement.

Another edge case.

Another feature that would make the first release more complete.

The two-month window forced us to make decisions.

The cycle was roughly divided into three stages.

Discovery — 2 weeks

A Focus Team primarily received a problem to solve, rather than a predefined backlog of implementation tasks.

The first two weeks were about understanding that problem.

The team would investigate questions such as:

• What exactly are we trying to solve?
• What alternatives do we have?
• What parts of the platform will be affected?
• What are the architectural implications?
• What is technically viable?
• What outcome do we expect?
• What can realistically be delivered within this cycle?

This mattered because the team wasn't simply being asked to execute someone else's solution.

They were expected to understand the problem well enough to participate in defining the solution.

The composition of each Focus Team also depended on the problem.

We considered the technical knowledge required, product context, individual strengths and opportunities to rotate people into different areas.

By the end of those first two weeks, the team needed enough clarity to move into implementation.

Build — 1 month

The next month was focused on execution.

And "focused" was the important word.

During this period, the Focus Team was protected from the normal stream of interruptions coming from the existing platform.

They weren't expected to constantly stop because of:

• legacy bugs;
• support requests;
• small improvements;
• routine operational work.

The Core Team absorbed that flow.

The Focus Team still had weekly follow-up and alignment, but it had autonomy to execute the approach defined during discovery.

The goal was to finish the month with something concrete and functional, not simply a larger backlog or a more detailed architecture document.

Stabilize — 2 weeks

The final two weeks were deliberately not used to immediately start another major initiative.

They were reserved for stabilizing what had just been built.

That included:

• technical debt;
• documentation;
• fixes;
• improvements discovered during implementation;
• decisions that had been simplified to meet the deadline;
• preparing the new capability to become a maintainable part of the platform.

This was an important part of the model.

If every Focus Team finished development on Friday and started another initiative on Monday, we would have optimized for visible delivery while continuously pushing the consequences of those deliveries into the future.

Speed wasn't useful if every new capability became someone else's cleanup project.

---

Someone still had to keep the lights on

Focus only works if someone is intentionally handling everything outside that focus.

That was the role of the Core Team.

While a Focus Team worked on a major product problem, the Core Team continued operating and improving the existing platform.

Its workflow was closer to Kanban because the nature of the work was different.

The Core Team handled things such as:

• bugs;
• incidents;
• support requests;
• operational needs;
• smaller product improvements;
• issues affecting the existing platform.

This work was not secondary.

It was what allowed us to create real focus elsewhere.

A common mistake when talking about innovation is to treat maintenance as an unfortunate distraction from "real" product development.

I came to see it differently.

Maintenance is product work.

Customers don't care whether an engineer is working on the future architecture if the product they depend on today isn't working.

The organizational challenge was therefore not to eliminate operational work.

It was to give both types of work an explicit place in the system.

---

Nobody owned innovation forever

The most important characteristic of Focus Teams was that they were temporary.

At the end of a cycle, the team dissolved.

Its members returned to the Core Team.

For the next problem, we created another Focus Team, potentially with a different composition.

There were two considerations behind that composition.

The first was obvious:

Put the right skills around the problem.

Some initiatives required specific technical knowledge or deeper context about particular parts of the platform.

But the second consideration was equally important:

Give different people the opportunity to participate in major product changes.

Over time, engineers could experience both sides of the system.

At one point, someone might be protected from operational interruptions while helping design a major new capability.

Later, that same person might be in Core, supporting the platform while another group had that opportunity.

The goal wasn't to make the distribution mathematically equal.

The goal was to prevent innovation from becoming a permanent organizational privilege.

There shouldn't be a permanent group of people who "build the cool stuff" and another group that "fixes everyone else's problems."

Rotation helped us avoid that division.

But it produced another benefit that eventually became just as important.

It moved knowledge.

---

Knowledge had to rotate too

When a Focus Team finished its cycle, simply moving people back to Core wasn't enough.

They had spent two months deeply immersed in a problem.

They understood:

• why the problem mattered;
• which alternatives had been considered;
• architectural decisions;
• how the new capability worked;
• trade-offs made during implementation;
• limitations of the first version;
• things future maintainers needed to know.

If that context remained only with the people who built the feature, we would simply be creating new silos every two months.

So knowledge sharing became part of the cycle itself.

The responsibility of the Focus Team didn't end when the feature worked.

When its members returned to Core, they were expected to help spread what they had learned.

The full cycle was closer to:

PROBLEM
   ↓
FOCUS
   ↓
DISCOVERY
   ↓
BUILD
   ↓
STABILIZE
   ↓
KNOWLEDGE SHARING
   ↓
CORE
   ↓
NEXT FOCUS

This changed the purpose of rotation.

Initially, rotation helped address a people problem: giving different engineers access to meaningful product initiatives.

But it also became a mechanism for distributing technical knowledge across engineering.

Instead of permanently assigning ownership of new areas to the people who created them, we deliberately tried to make those areas understandable and maintainable by the wider team.

Knowledge sharing wasn't something we expected to happen naturally.

It was part of the operating model.

---

Product Engineering instead of methodology

Parts of this model will sound familiar to anyone who has worked with agile development.

Focus Teams used several principles associated with Scrum and iterative product development.

Core operated with a flow closer to Kanban.

But describing the system as "we used Scrum and Kanban" would miss the interesting part.

The frameworks weren't the solution.

The organizational design around them was.

We had four things we needed to protect simultaneously:

Innovation — build the major capabilities required for BLiP to evolve.

Operations — keep the existing platform and customer experience working.

People — allow different engineers to participate in meaningful product evolution.

Knowledge — progressively spread understanding of the new platform across engineering.

I think of the principle today as:

Build the future. Run the platform. Grow the team. Share the knowledge.

Scrum or Kanban could help organize work inside parts of that system.

But neither answered the organizational question by itself.

---

Constraints helped us make product decisions

The fixed duration of a Focus Team was also a product management mechanism.

A team couldn't simply keep working until everyone agreed the solution was perfect.

We had roughly two months.

That forced conversations about:

• scope;
• priorities;
• MVP;
• technical complexity;
• trade-offs;
• what was essential for the first version;
• what could wait.

This was particularly important while MensagemHub was becoming BLiP.

There was a lot we wanted to build.

If every major capability became an open-ended project, we would have struggled to create momentum across the product.

The deadline created a useful constraint.

The question wasn't:

"What would the perfect version of this capability look like?"

It was closer to:

"What meaningful version can we understand, build and stabilize within this window?"

That distinction encouraged decisions.

And product development is, to a large extent, the discipline of deciding what not to build yet.

---

From one Focus Team to two

For approximately the first year, the model operated with:

1 FOCUS TEAM
      +
1 CORE TEAM

That reflected the size of the engineering organization and the number of major initiatives we could reasonably run at the same time.

But BLiP was evolving, and the team was growing.

Eventually, one Focus Team became a limitation.

So in the second year, the model evolved into:

FOCUS TEAM A ──→ Major Product Problem A

FOCUS TEAM B ──→ Major Product Problem B

CORE TEAM ─────→ Platform Operations

Now we could attack two significant product problems in parallel while a third group continued protecting the existing platform.

For me, this evolution is an important part of the story.

The model wasn't a methodology we were trying to defend.

It was a response to a particular organizational problem.

When the context changed, the model changed.

Had we treated the original structure as a set of rules that needed to be preserved, it would eventually have become another constraint on the organization.

Instead, the structure existed to serve the product and the team.

---

What this taught me about Product Engineering

Looking back, one of the most important lessons from that period is that prioritization alone doesn't create focus.

You can mark something as the highest priority on a roadmap, but if the people responsible for it are interrupted by incidents, support requests and unrelated work every day, it isn't really the highest priority.

Focus needs to be designed into the operating model.

At the same time, protecting focus shouldn't mean treating operational work as inferior work.

Someone still needs to run the platform.

Making that responsibility explicit helped us recognize it as a real part of product engineering rather than noise surrounding product development.

I also became much more cautious about permanently separating innovation and maintenance.

It can look efficient on an organizational chart, but it can create knowledge silos and very different experiences for engineers.

Rotation gave us another option.

People moved.

And because people moved, knowledge could move with them.

But that only worked because knowledge sharing was intentional. Documentation, stabilization and context transfer had to be treated as part of delivering the capability, not as optional work to do later.

The fixed two-month cycles taught me something else: constraints can improve product decisions.

A deadline forced us to confront scope and trade-offs early.

Instead of allowing a team to pursue the theoretically best solution indefinitely, we had to decide what was meaningful, feasible and sufficient for that stage of the product.

And perhaps the biggest lesson was about team structure itself.

Teams don't always need to be designed around permanent areas of ownership.

In some situations, temporarily assembling the right combination of people around an important problem can create a different kind of momentum.

That doesn't mean temporary teams are universally better.

It means organizational structure should be treated as something we can design around the problems we actually have.

During the transformation from MensagemHub into BLiP, our problem was not simply that we needed to develop features faster.

We needed to build a new generation of the product while continuing to operate the existing one, develop the people building it, and prevent knowledge from becoming concentrated in a few individuals.

The Focus Team + Core Team model helped us create capacity for that transformation.

Not because it was a perfect methodology.

But because, for that stage of the product and organization, it addressed the problem we actually had.

We needed to build the future without stopping the present.