A well-built team is the key to success—a truth as old as time. But how do you know a team is built right?
When I joined the design team at one of the biggest banks in my country in 2023 as a senior product designer, the atmosphere was great. The team was welcoming: colleagues showed me around the office, took me to the best local spots; everyone was open, inspired, and eager to share their work. Designers cared about the product and were genuinely proud of what they were building: the Super App, which combined a fintech application and marketplace. It felt like a dream team.
As soon as I started on the project, I began noticing signals that something was off:
This Super App was only being designed from the fintech side, while the marketplace team had no idea about the project. The fintech team ignored the marketplace UX and pulled the blanket toward themselves. The app’s home screen, for example, displayed a bank card and transaction history—closer to a classic banking app than anything marketplace-related.
The user experience, its strengths and weaknesses, was simply ignored, despite the 2 million users. The task wasn’t broken down at all. Designers had no roadmap, clear ideas, or even a deadline. Progress wasn’t even measured. Tasks lived across Jira, Telegram chats, and verbal agreements. When managers assigned new work, designers pushed back, saying they were already overloaded, but when asked to list what they were actually working on, they'd piece it together from memory and scattered chat threads, inevitably missing things. Soon enough, the designers had earned a reputation for being unreliable.
Quality control was ad hoc and unpredictable. Mockups contained logic errors, typos, and often ignored edge cases. The work looked like a concept rather than a polished product meant for customers.
Finally, there was no way to tell where the problems actually came from. It was impossible to diagnose whether missed deadlines were because of poor process, weak task briefs or gaps in individual skill. Designers spent significant mental energy just keeping track of their own workload—and with that kind of overhead, even the strongest workers make mistakes.
Despite clear signals of trouble ahead, the team was happy. Genuinely happy. They liked working for the country’s largest company and believed they were building a market-defining product. Spoiler alert: three years later, the Super App still hasn’t shipped. The project was paused two weeks after I arrived, the work went into a drawer, and the team was demotivated for weeks.
Either way, their cheerfulness wasn’t the problem. The real problem was what that cheerfulness hid: work without a destination. Their output wasn’t creating real value, neither for the business nor for customers.
That’s deadly in product work. A product designer’s job is to understand the business context and constantly ask “why,” “for whom,” and “to what end.” Without answers to these questions, the work turns into a random exploration of ideas and copying others’ solutions without understanding their strengths and weaknesses. In this situation, a designer cannot objectively evaluate the outcome of their work, begins to doubt their own decisions, and is unable to defend them in front of stakeholders. As a result, this leads to endless iterations and rework without clear progress. We’ve seen this happen in our company as well.
Rebuilding from scratch
After laying out everything I’d observed for the CPO, I was asked to lead the design effort. My proposal was thorough: sprints, reporting, clear task briefs, and a consistent design process. My first organisational challenge was to avoid the previously described oddities. Our goal: to redesign the bank app quickly and stay competitive in a fast market.
So I started with one question: how do we tell whether designers are actually delivering value? You can’t manage what you can’t measure. We needed objective, repeatable ways to see the work and the bottlenecks.
During the first month, we moved 100% of task tracking into Jira with weekly planning and one-week sprints. Designers felt immediate relief—no more keeping track of everything in their heads. Managers resisted; retraining them required support from their own leadership. Since I hadn't yet earned enough authority to push this through alone, I enlisted the help of a senior manager who shared my diagnosis. We also introduced a filter for unplanned urgent requests: only the CPO or lead could greenlight them, and only against hard criteria: regulatory requirements, critical bugs, or key OKRs. Most "urgent" tasks didn't qualify anymore.
Months two to three
We introduced hour-based task estimates and a sprint success metric: 80% of committed tasks reaching CPO review. The 80% threshold wasn't arbitrary: roughly 20% of work was historically unpredictable (regulatory demands, leadership requests), so we built that buffer in. Six consecutive failed sprints meant termination. That was a hard line, but it forced clarity: some designers absorbed feedback and improved; others repeated the same mistakes, sprint after sprint.
The first five sprints for everyone, including me, came in at 30-40%. That was painful and revealing. The CPO gave blunt feedback, and many designers took it personally. But the weekly cadence meant we could see patterns: tasks were poorly scoped, estimates were intuitive rather than structured, and designers routinely skipped discovery.
Six months in
We formalised task breakdown into mandatory stages with clear completion criteria:
- Briefing (3–5h):
The designer studies the task, gathers materials, and aligns with the PM on success criteria and required steps. The lead must monitor this, as inexperienced designers often miss questions that can derail work later. If the PM lacks clarity, the designer either finds the necessary info (as a separate task) or returns it to the backlog.
2. Benchmark (up to 10h):
Mandatory for new products or redesigns. The designer reviews local and foreign markets, compiles a summary table, generates hypotheses to test, and agrees with the PM on which hypotheses to validate and what to borrow or avoid.
3. UX concept (up to 16h):
The designer maps entry points and the core user scenario without deep detail. This is a quality gate that reveals weaknesses in the prior steps. If the designer struggles, that means they lack information and should go back one or two steps. If that doesn’t help, the task may not suit that particular designer. The design team should self-validate, but if the designer and PM are unsure, they must send it for CPO review.
4. Research (if necessary):
The designer has to create a separate task for unknowns rather than letting them silently block progress. The lead should watch these initially because, sometimes, there are faster ways of gathering data.
5. Finalisation:
Polishing edge cases, error states, cleaning up mockups, checking copy and logic.
6. Post-review:
Design review with engineers, evaluation of results in production, small fixes, etc. Different companies may have unique task types. The main thing here: don’t be afraid to experiment with breakdown and add/remove stages as needed.
We also standardised mockup annotations, since, previously, designers worked in different languages and styles, which slowed every handoff. Resistance faded after a few successful presentations in the new format. Review access was tightened: only designers consistently closing sprints and shipping approved work could participate. Quality at that stage improved, and others learned to ask sharper questions. The headline result: approval iterations with the CPO and CEO dropped from five rounds to one.
A year in
The system was working, but we started noticing designers optimising for sprint closure at the expense of solution quality. That called for a different kind of fix.
Fixing the pipeline and closing loopholes
As we rebuilt the process, designers learned how to game it by hitting high sprint completion rates, but focusing on the metric itself: they broke down flows into many small tickets, ran redundant “briefings,” or produced shallow research artefacts just to tick a box. Sprint completion looked close to perfection; end-to-end quality did not.
It was time to tighten the system, so we did:
- Reduced the number of people who could approve work before CPO review—only senior, trusted reviewers (initially myself and one experienced designer).
- Banned excessive task breakdown: end-to-end flows had to be presented as a whole picture, not a bunch of small, separate tickboxes.
- Introduced a Blocked status for external dependencies (legal, infra) so teams weren’t unfairly penalised.
- Added outcome metrics: number of tasks passing CPO/CEO review and number of features shipped to production.
The change shook the team for a short period; numbers dipped for a couple of sprints, but it was intentional. But in the end, we chose outcome quality over numbers. Still, two designers continued playing the metric game, leaving me no choice but to part ways with them.
The payoff was real
Over the next 18 months from the story’s start, our team shipped repeatedly and drove measurable results. Our bank issued more than 5 million cards and jumped to 4th place out of 35 banks in the country. In 2025, we issued 4× more cards than the nearest competitor.
But what is more important, designers gained trust because we consistently made the process transparent, stopped fearing criticism, and learned to make effective mistakes. Initially, CEO alignment could take up to six iterations and a lot of feedback. A year later, this was down to 10 minutes.
This experience taught me a lot. Building a happy team is easy; building a team that drives impact takes a lot of work. Metrics, structure, and accountability matter, but so do trust, guidance, and a shared sense of purpose.
Process needs constant calibration, otherwise people find ways to optimise for the metric instead of the outcome. Transparency also doesn't suit everyone; some disengage, and you have to be willing to part ways when the time comes.
And, in the end, when you see a problem you believe you can fix—say so and take ownership. Most people don't. That hesitation is your opportunity.
