2. Case Study - Changing Product Culture at Creditas

Changing the product culture at Creditas was a significant and complex journey, but we successfully implemented a series of tactics that improved our teams' alignment, motivation, and overall delivery speed. Here are some of the key steps we took, along with lessons learned along the way.

1. Building Real Squads

Previously, we didn’t have real squads. What we had were disjointed technology teams that lacked clear objectives and alignment with other areas of the business. To address this, we created cross-functional squads, each consisting of a Product Manager (PM), a User Experience (UX) Designer, and a team of Developers. These squads were tasked with focusing on specific business objectives and tracking key KPIs related to conversion rates, revenue, or other vital business metrics.

We made it clear that each squad existed to solve a specific business problem, and we worked to ensure that the operations team was also involved and aligned with the squad's goals. Operations teams began to understand that the technology squads were there to help them achieve their objectives as well.

2. Adopting a Dual Track for Discovery and Delivery

We introduced the dual track model for discovery and delivery, ensuring that the entire squad, including PM, UX, and Developers, participated from the start. Previously, only the PM was involved in the discovery phase, but we changed this so that everyone could understand the problem, anticipate risks, and contribute to finding solutions from day one.

For example, when a new idea came from the credit or operations team, everyone in the squad would join in understanding the rationale, potential impact on users, and how it could benefit the business. This approach ensured that everyone in the squad was aligned and had context on the decisions being made.

We implemented business-oriented ceremonies to keep everyone motivated and aligned with the squad’s goals. Initially, we had defined the motivation behind the squad's work, but we reinforced this motivation regularly. We started with a refinement workshop where the team would understand the business motivation behind each feature, define acceptance criteria, and think through different use cases.

We also began to delegate the writing of business stories to developers. Instead of relying solely on the PM, developers were responsible for defining the business motivation, impact metrics, and the solution's effect on business outcomes. Although this was challenging at first, with long refinement sessions, the process improved over time.

4. Product Checkpoints and Communication

We established regular product checkpoints twice a week—on Tuesdays and Fridays. On Tuesdays, the team could talk about all the technical details they were working on, while on Fridays, the focus shifted to the business motivation behind their work. Everyone from each squad had to explain what they were working on and why it mattered from a business perspective.

Initially, this was difficult, as developers were not used to talking about the business impact of their work, but through consistent questioning and coaching, we helped them align their work with broader business goals.

5. Hiring Developers with a Business Mindset

We realized that our hiring process for developers needed to change. Previously, we focused solely on technical skills and cultural fit, but we started placing a strong emphasis on business understanding. We wanted to hire developers who cared about how their work impacted the business.

Involving PMs and UX designers in the interview process allowed us to ask more business-related questions and ensure that candidates were aligned with our goals. We even began to include business challenges in the onboarding process, where new hires had to solve real business problems by interacting with stakeholders, providing them with a deeper understanding of the company's needs right from the start.

6. Breaking Down Stories and Frequent Releases

To overcome the fear and stress associated with big releases, we encouraged the team to break down stories into smaller, deployable units of value. We focused on delivering something that was ready for production as soon as possible, even if it wasn’t yet visible to users.

For example, backend work could be deployed with feature flags to ensure it didn’t go live until the full solution was ready. This approach encouraged more frequent releases and helped reduce the fear around deployments.

7. Creating Component-Based Teams

We identified that a significant issue was the dependency between teams when working on shared parts of the system. To solve this, we created component-based teams responsible for core components of the system that multiple squads relied on, such as the credit engine or pricing algorithms.

These component teams were responsible for building generic yet specific enough components that could be reused by other squads, enabling faster delivery and reducing dependencies. This model improved our delivery speed and allowed squads to focus on functional improvements.

8. Embracing Failure and Experimentation

We shifted our mindset to embracing failure as part of the learning process. We encouraged teams to conduct experiments not only with new features but also with internal processes. For example, we ran A/B tests with users before building large features and experimented with different project management methodologies like Scrum or Kanban based on what worked best for each squad.

We also introduced post-mortems for any major issues, whether related to product definitions, bugs, or architectural decisions. This allowed us to identify the root causes of problems and continuously improve.

9. Retrospectives and Continuous Improvement

Finally, we enhanced our retrospective sessions to make them more impactful. Teams were encouraged to openly discuss what wasn’t working and why. We tracked delivery metrics and adapted them as needed. These retrospectives became a safe space for teams to voice concerns, acknowledge misalignments, and propose new ideas for improvement.

Conclusion

Changing product culture at Creditas required a comprehensive shift in how we structured our squads, aligned them with business goals, and empowered them to take ownership of their work. By focusing on business motivation, fostering collaboration across roles, encouraging experimentation, and building a culture of continuous improvement, we transformed how our teams approached product development. These changes ultimately led to faster, more aligned, and more impactful deliveries.