How we shipped a core product rebuild in one quarter without a single sprint.
At the end of last year, we ran a double experiment: brought together a team from across different units and traded our beloved Scrum for Kanban. All to rethink the architecture of one of our core products so it could grow and scale faster. One constraint: users shouldn’t notice anything had changed. Metrics had to hold.
I’m Dmitry, Frontend Area Lead at Manychat. Here’s what happened — spoiler: it worked, and we’re doing it again — and when it might be worth trying for you, especially if you’re staring down a project full of unknowns.
Where the problem came from
Manychat is a marketing automation platform for messengers. One of our core features is the Flow Builder: a canvas where you drag, connect, and configure automation sequences. Powerful tool but it is not the friendliest for beginners.
So we built EasyBuilder — a simplified interface with pre-packaged solutions. No canvas, just pick a scenario, walk through a few steps, configure in a couple of clicks. Done.
Experiments showed good results. Adoption grew. Then we hit the ceiling. It became clear that to keep growing, the product needed a fundamental rethink.
The problem was structural: EasyBuilder (front) and the Flow Builder (back) existed as two parallel systems. The frontend had no knowledge of the flow structure — it just collected form values and sent them to the backend, which assembled the automation from a rigid template. Every new scenario meant starting from scratch: adding anything new meant hardcoding it manually.
Rebuilding EasyBuilder wasn’t just a technical challenge. It also came with an organizational one. At Manychat, we have the following setup: a core team maintains the platform, a growth team ships features on top. One builds the foundation, the other builds on it. This is an intentional structure.
The catch was knowledge transfer. Whichever team built the new foundation first, the other would eventually need to pick it up — with zero context. Building that bridge from scratch would have been expensive and slow.
Two challenges arrived together: technical and organizational. They needed a single answer.
Tiger team
The obvious move was to spin up a cross-functional team and hand them the task. We figured out pretty quickly that wouldn’t work. Every team still had its own backlog, its own priorities. Work on Easy Builder would have dragged on. And we needed this done in a quarter max.
What we actually needed:
- Full isolation from ongoing area priorities — a team thinking about exactly one thing
- Not a standard headcount (two backend, two-three frontend, designer — too many), but the specific people for the specific job.
- No onboarding budget: the task required people who already knew the context
The idea was to build a standalone team pulled from their regular units for the project, then return when it’s done and distribute expertise across their teams.
These are the areas that donated their teammates for the project.
That became the Tiger team. Yes, same as for NASA’s Apollo 13. We aimed high🙂.
The team: two frontend engineers, one backend engineer, a staff engineer from the infra team, and me — also a frontend, but acting as a tech process lead throughout the project. A PM and designer synced with us as needed rather than full-time.
Kanban instead of Scrum
The team was only half the experiment. The other half was the process.
Manychat runs on Scaled Scrum. Teams share a unified backlog, live by sprints, retrospectives, PBRs, and the rest of the Scrum ritual calendar. Large tasks get broken into small, predictable pieces so teams can move steadily and keep metrics stable. The principle: a team enters a sprint with minimal uncertainty, because you have to deliver within a fixed window.
Our task was the opposite of that. We didn’t know how much was actually in there. It was a Pandora’s box: you open it and you don’t know what you’ll find. Scrum would have forced us to package that uncertainty into sprints — break it into tasks, estimate, commit to a fixed cadence. Any estimate would have been a guess, and we’d have burned energy planning things we didn’t yet understand. For example, the first two weeks were research only. We had no concrete tasks to put in a sprint. Scrum wouldn’t have worked at all.
So we went with Kanban. Without sprints but with a roadmap instead. We moved with the whole epic from start to finish. Reprioritize when the task demands it. For a company where Scrum is the basic framework, this was an experiment inside an experiment.
Tiger team in action
The first two weeks looked like a startup. Every day in the office, in meeting rooms — brainstorming, challenging each other’s architectural proposals.The scope of the task was opening up gradually, and we needed to understand it before we could move.
A fragment of our work roadmap from October–November.
When we had a foundation, we started moving through the roadmap. Whole epics at a time. When something unexpected surfaced, we dealt with it on the spot and kept going.
The PM and designer weren’t in the room full-time — they joined weekly syncs and worked asynchronously: we’d hand off a task, they’d discuss it, come back with a decision and a design. That worked fine for most of the project. Where we hit friction was when a product decision was blocking a technical one, and the PM wasn’t available. Some sizable tasks stalled in the queue because we couldn’t move without a call.
In the end, 90% of the project was built in this mode. The remaining 10% — final fixes and polish — was handed off to a product team, who wrapped it up within a single sprint.
What we actually built
Instead of writing custom code for every new scenario, we created a meta-language on top of the Flow Builder that lets you assemble forms and configure scenarios automatically. Unlike EasyBuilder, where the frontend and backend operated as two separate systems via established and rigid contract, Quick Automations — this is how we called it, works with a single flow builder entity end-to-end.
Before, adding a new scenario meant a developer hardcoding it from scratch. Now, a developer isn’t needed at all. A product manager can come in, configure a scenario themselves — and a ready-made form appears for the user. No developer involvement, no new sprint per configuration.
This is how it looked for a product manager to create a new automation scenario, using Flow Builder. On the right part — the result the user will see.
And this is the user interface, the same as it was for Easy builder 1.0.
Knowledge transfer in practice
One of the expected benefits of this setup was knowledge transfer. The people who built the product went back to their permanent teams — taking everything they learned with them. That made it easier to land the solution in any area and keep improving it in parallel.
They ran workshops for engineers — walked through how the new system works, helped colleagues tackle tasks in ways that built understanding rather than just output. They ran sessions for product teams on how to configure scenarios and build new automations without involving developers.
That was the goal: teams who inherited the product can move independently — add new configurations, run experiments. The tiger team is gone, but what it built lives in the product and in the people.
When to use this
A temporary project team isn’t a universal tool. Neither is Scrum or Kanban. Before reaching for either, it’s worth asking: is the process serving the work, or is the work serving the process?
This project helped us answer that question. Here’s what we learned about when this format makes sense — and when it doesn’t.
It is definitely worth trying when:
- The task is one-time, but strategically critical. Not your regular product flow, but something that needs to be done once and done right — laying a foundation that features will build on.
- The scope is unpredictable. If you don’t know how much is actually in there, sprints will create pressure where you need flexibility.
- The task doesn’t fit the standard process. Especially if a large task can’t be broken into sprints without losing its meaning.
- The people you need are spread across teams. If the expertise is distributed across different units, and those people already know the context — no onboarding required.
And it may be less effective if:
- The task is small and fits cleanly into a regular sprint. No need to build a separate structure.
- The company isn’t willing to temporarily release people from their teams. Without that, a tiger team won’t fly.
- There’s no clear endpoint. The team risks becoming permanent — which is a different story entirely.
As for our case the experiment worked 100%. We got a solution for the problem. App metrics held. We’re doing it again.
Top comments (0)