Rewriting an existing product is often a cost and technology-centric exercise that can feel like a joyless necessity. But instead of replacing like-for-like and providing a carbon-copy of the old product, you should see the rewriting effort as an opportunity to innovate, to create more value for the users and the business, as I explain in this article.
Similar to a company experiencing financial debt, products can incur “technical debt”: This happens when wrong or suboptimal architecture, technology, and coding decisions are taken. Consequently, the architecture may not be as loosely coupled as it should be, and the code may be messy rather than clean. This article explains why product people should care about technical debt and it offers strategies for addressing it.
Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals.
Software quality is often perceived as something the nerds should worry about. But it can significantly impact customer satisfaction and brand value; the total cost of ownership and life expectancy of your product; and the product’s competitiveness. This post explains what product owners can do to help their development teams get quality right.