AI has made building easier.
But building the right thing is still hard.
Ten articles every week on what is happening across product, research, design and engineering. Curated by Rory Madden to help teams decide what to build.
Explore the editions ↓The archive
Traditional retrospectives often fail to drive meaningful change due to three key limitations: teams lack the authority to implement identified improvements, they struggle to determine which changes will actually add value, and the bi-weekly cadence means problems persist longer
Read edition ↗The strength of cross-functional teams lies in their diversity of skills and perspectives. However, this same characteristic presents a unique challenge: functional isolation. With typically just one person representing each speciality, if someone lacks proficiency in a critical
Read edition ↗Cross-functional teams are tasked with achieving outcomes rather than outputs. This means that they can streamline the traditional product delivery lifecycle to remove the unnecessary blocking handoffs.
Read edition ↗Functions are optimised for efficiency. But the efficiency of each function does not translate to the efficiency of the system. You would think that if each function is becoming more efficient, then how can it slow down the system? Backlogs.
Read edition ↗In the push to empower cross-functional teams, one of the biggest challenges isn't technical, cultural, or even organisational—it's financial. Specifically, the division between capital expenditures (CapEx) and operating expenses (OpEx).
Read edition ↗One of the biggest challenges when shifting from a project-based model to a product-based model, is that the different functional experts can become isolated from each other. Instead of working, and often sitting, together, functional experts are scattered across multiple teams.
Read edition ↗If we move to long-lived, decentralised teams, what happens to the functional managers who were leading the functions? People belong to their team now, and not a function anymore so there is no need for resource allocation and budgeting.
Read edition ↗I think the term "Product Team" is often misused in the software industry. Often it is used interchangeably with the teams building the product. However, a product is typically too large for a single team to build, requiring multiple teams to focus on different value streams. The
Read edition ↗"Empowerment sounds great on paper, but just telling teams 'you're empowered now, go build great things!' is a recipe for disaster" Ever heard this pushback before?
Read edition ↗Centralised decision-making in product development may seem effective initially, just as the Soviet Union out-grew the US economy for almost two decades, but it ultimately stifles innovation and adaptability.
Read edition ↗Developer platforms are designed to accelerate software delivery by standardizing tools, workflows, and infrastructure, reducing cognitive load for teams. However, when platforms become overly prescriptive, they can stifle innovation and slow down progress.
Read edition ↗According to the 2021 Design Systems Survey, only 40% of the systems were successful. Design systems often fail despite their potential to drive consistency and efficiency, not due to poor quality but due to low adoption.
Read edition ↗I think this one might annoy some of the readers out there, but the Center of Excellence (CoE) model is an anti-pattern, particularly when related to a service that every product team needs like Research, Design or DevOps.
Read edition ↗