The Product Shelf

All Tests Passed. So Why Did It Break?

The tests passed. The release went live. Then customers started receiving incorrectly allocated refunds. What did the checks miss?

In this episode of The Product Shelf, we follow Mercato, a fictional online store, to explore what passing tests actually tell us—and how Product Managers can use that evidence when deciding whether a change is ready for customers.

Mercato has updated its returns process. Full returns work. Partial returns work. Refunds to a bank card work. But when a customer returns one item from an order paid with both a gift card and a bank card, the system distributes the refund incorrectly. The combined amount is correct; where the money goes is wrong.

The successful checks and the customer problem can both be real. Understanding why requires a closer look at the scenarios tested, the conditions used, and the outcomes actually checked.

What does a passing test establish?

A test can confirm an expected outcome under specific conditions while leaving other situations unexplored. We examine how testing two features separately can miss their interaction, and how a check that verifies the refund total can overlook an incorrect allocation between payment methods.

We also discuss why clear business rules matter. If the implementation and its tests share the same mistaken assumption, they can agree with each other while producing the wrong customer experience.

Unit, integration, and end-to-end tests

Different tests provide evidence at different scopes. We explain what each approach can reveal, why a broader test still depends on the scenario it exercises, and how simulated external services can make testing practical while leaving questions about the real integration.

The aim is to understand which checks address the risk in front of the team, without needing to write the tests yourself.

Why high code coverage doesn’t guarantee correct behavior

A coverage report can show that code was executed without establishing that its results were checked adequately. Hundreds of passing tests can still leave an important payment combination untested.

We distinguish code coverage from coverage of customer behaviors, and explain why skipped or blocked checks should remain visible in a release discussion.

We also explore how test data, configuration, and differences between testing environments and production can create gaps. These are possible sources of uncertainty; the missing mixed-payment scenario explains Mercato’s particular incident.

What can Product contribute before release?

Product Managers and Product Owners can help clarify expected behavior, identify relevant customer situations, and assess the consequences of failure. We explore practical questions to discuss with Engineering and QA:

• Which important customer outcomes could this change affect?
• What did the tests actually verify?
• Which scenarios were simulated, skipped, or blocked?
• What uncertainty remains, and what evidence would reduce it?
• Would a narrower release genuinely avoid the unresolved risk?

When a defect reaches customers anyway

The episode also examines containment, checking a correction, and reviewing affected transactions. Reverting software does not automatically repair financial operations already completed, and rerunning the original tests leaves the original gap untouched.

Drawing on Testing, Bugs, and QA for Product Managers, this episode connects software testing with the decisions Product teams face about quality, customer impact, and release readiness.

No coding knowledge required.

Why Does a Small Feature Need Three Teams?

A delivery date beneath a product’s price looks like a small addition. So why does it need three engineering teams to launch?

In this episode of The Product Shelf, we follow Nómada, a fictional online store, to uncover the systems and responsibilities behind a seemingly simple customer request.

The shopping team can add the date to the page. But inventory knows where the item is available, and the delivery team manages the connection to the shipping provider. Before the feature reaches customers, those capabilities need to work together—and any missing pieces need to fit into different teams’ plans.

We use this case to explain how software architecture and team dependencies affect scope, delivery dates, and the customer experience.

Depending on a system versus waiting for a team

A product may need another system to function without requiring its owning team to develop anything new. If the information already exists through a supported interface, the team building the feature may be able to use it independently.

When that interface needs extending, a delivery dependency appears. We explore how to distinguish the work required from the time spent waiting, and why that difference matters when discussing an estimate or committing to a launch.

How APIs support independent work

An application programming interface, or API, provides an agreed way for systems to communicate. A clear agreement can let teams change their internal implementation without forcing everyone else to change with them.

That agreement needs meaning as well as a data format. Does “delivery date” mean arrival at the customer’s address or departure from the warehouse? Does it include processing time? Can it change before checkout?

These questions connect technical interfaces with the promise the product makes to customers.

Why more services don’t automatically mean fewer dependencies

Splitting software into smaller services can support independent deployment and clearer ownership. It also introduces communication and operational work.

If every new delivery rule still requires several services to change together, the teams will continue to coordinate. We examine why the design of those boundaries matters, and how to distinguish a technical limitation from a conflict between teams’ priorities.

What happens when the estimate is slow or unavailable?

The dependency remains after launch. If Nómada waits for the shipping provider before displaying the product page, a slow response can affect the shopping experience.

We discuss what genuinely needs to wait, what could load separately, and how pending or failed requests change the states Product needs to design. Reusing an earlier estimate also involves a decision about how accurate and current the information must be.

Turning dependencies into a delivery plan

Before promising a date, Product can work with Engineering to understand:

• Which information and capabilities the feature needs.
• What already exists and what requires development.
• Which work can happen in parallel.
• Which sequence determines the earliest possible launch.
• Whether a narrower first release removes a real dependency.
• Who follows the complete customer outcome across teams.

A smaller launch might support one region or one warehouse first—but only if that restriction genuinely reduces the unresolved work and still provides useful information to customers.

Drawing on Software Architecture for Product Managers, this episode helps Product Managers and Product Owners turn architectural conversations into clearer decisions about scope, sequencing, and release commitments.

No coding knowledge required.

Why Is Your Engineering Team Taking Longer to Deliver?

A small discount feature used to take a week. Now the engineering team estimates three—even though they know the product better than ever. What changed?

In the first episode of The Product Shelf, we follow Mercato, a fictional e-commerce platform, to explore how the state of a software product affects the effort required to change it.

Mercato started with a small catalog, a shopping cart, and a straightforward way to pay. Then came promotions, subscriptions, new payment methods, external integrations, and additional markets. Each capability added value, while some also introduced relationships and rules that future changes would need to respect.

Now a discount that looks simple on screen requires the team to investigate existing calculations, review dependencies, and check that other purchasing behaviors still work.

When product growth increases the work behind a change

More functionality can mean more interactions between parts of the system. A new promotion might affect subscription benefits, shipping conditions, payment amounts, and partial returns.

We explain how dependencies and coupling influence development effort, and why some complexity belongs to the business itself. A well-maintained product with demanding commercial rules can still require considerable work to modify.

Where technical debt contributes

Some implementation decisions introduce difficulties that could be reduced. Mercato’s team may have duplicated a calculation to meet a campaign deadline, postponed automated checks, or allowed one component to accumulate responsibilities.

Those decisions can create recurring work when the product changes again. But a quick solution is not automatically a mistake. We examine when accepting a technical limitation can be reasonable, and why its consequences deserve another look as the product evolves.

We also distinguish technical debt from bugs, routine maintenance, and investment in genuinely new capabilities. Treating every technical task as debt makes it harder to understand what needs attention and why.

Why small changes need substantial testing

Writing the new behavior is only part of the work. The team also needs to understand the existing implementation and check that customers can continue using the behaviors they already rely on.

We explore regressions, repeated manual checks, and the role of automated tests. Some verification remains necessary because the product supports more situations than before. Other effort may come from avoidable limitations in how the software and its tests are organized.

What can a Product Manager do?

A useful conversation begins by understanding what sits behind the estimate. This episode explores questions such as:

• Which parts need investigation, implementation, and verification?
• Does the estimate describe effort, elapsed time, or both?
• Have the same difficulties appeared in recent deliveries?
• Which upcoming roadmap initiatives will encounter this limitation again?
• What focused improvement could reduce that recurring work?
• Could a smaller scope meet the immediate need with acceptable consequences?

We discuss how Product and Engineering can compare alternatives, make assumptions visible, and evaluate whether a technical improvement produces the benefits that justified it.

The cost of postponing—and the cost of intervening

Repeatedly prioritizing new features can leave less capacity for future delivery. Broad refactoring or a rewrite can also consume substantial resources without a clear return. The decision depends on the limitation, its risks, and how frequently the affected capability will need to change.

Drawing on Technical Debt for Product Managers, this episode connects accumulated technical decisions with roadmap choices and the opportunities a team can pursue next.

No coding knowledge required.