Product Management and the Decisions That Outlive the Roadmap

I’ve been thinking about how we judge product decisions. At launch, everybody can see the new features, the interface and the demonstration that works. A few years later, someone is dealing with an architectural shortcut, an expensive change request or a customer whose needs have moved on. Those problems often begin with choices made long before the launch.

Product management involves deciding where to spend engineering effort, which constraints to accept and how much room to leave for change. The consequences can last longer than the roadmap that justified those decisions.

Four machines come to mind when I think about this: a British battleship, Nintendo’s Game Boy, the American B-52 bomber and the Soviet MiG-25. Quite an odd group, I know. Their designers faced very different problems. The connections are useful when you look at the decisions behind each machine.

The Dreadnought and the whole product

In 1906, HMS Dreadnought arrived with ten 12-inch guns and steam turbines. Battleships of the period usually carried a few heavy guns alongside smaller weapons. Dreadnought’s combination of firepower and speed pushed other navies to reconsider their fleets.

Admiral John Fisher and the people designing the ship were thinking about how its components worked toward a shared purpose. That matters in product management too. A reporting feature can be excellent while the data-entry process makes it painful to use. A team might meet its own delivery target, then discover the customer still gets stuck between departments.

Good product decisions account for these handoffs early. A naval arms race, with its enormous costs and military pressures, offers a limited analogy for commercial products. The point worth carrying across is the attention given to the complete job.

Gunpei Yokoi knew when to use old technology

Nintendo released the Game Boy in 1989 with a monochrome screen. Colour display technology already existed. Gunpei Yokoi, one of the people behind the handheld, advocated lateral thinking with withered technology. He wanted to find inventive uses for mature, well-understood components.

I keep coming back to that idea when a product team wants to add new technology. Take a computer-vision application that uses a camera to check parcels. The team could process images in the cloud, or evaluate a compact model running on the device so it can respond locally. The choice depends on the network, operating conditions, device cost and maintenance workload. You would have to test those conditions before committing to an architecture.

Yokoi’s approach gives product managers room to ask whether a familiar component can deliver the experience users need. There is plenty of engineering involved in making ordinary technology work reliably.

A B-52 may still be flying a century after its design

The B-52 entered US Air Force service in 1955. Its original projected life was around twenty years. Then came the B-58 Hustler, a supersonic bomber that entered service in 1960. The B-58 retired in 1970. The surviving B-52 fleet is still operating, and the Air Force plans to keep it flying into the 2050s.

Think about that for a moment. Aircraft designed in the 1950s may still be carrying out missions roughly a century later, while a bomber that arrived after the B-52 has been retired for decades.

The B-52’s design provided a platform that could be adapted to new equipment, missions and weapons. The Air Force has repeatedly invested in that adaptability. Its current modernization plans include engines, radar and communications systems. A July 2026 US Government Accountability Office report also describes serious cost and schedule challenges. Longevity takes engineering work and money, even when the original design gives you room to change.

That is where product philosophy comes in. A decision about interfaces, replaceable components or serviceability can affect customers many years later. Some products will need to be retired as requirements change. Others may keep serving their purpose through multiple generations of technology. A product manager should think about both possibilities while the design is still young.

The Foxbat and the attraction of big specifications

The Soviet MiG-25 Foxbat entered service in 1970 as a high-speed interceptor and reconnaissance aircraft. Its published speed was about Mach 2.83. When Soviet pilot Viktor Belenko defected to Japan in 1976, analysts gained a closer look at a machine built for a particular mission.

The aircraft used powerful engines and relatively straightforward electronics, with limited use of advanced materials. Those choices made sense in the context of the task the aircraft was intended to perform.

Product discussions have their own impressive figures. A model accuracy score or a speed benchmark can easily take over a presentation. I’d want to understand the conditions behind the measurement and whether the result relates to a job customers will actually do.

The Foxbat was a capable specialist. Judging it by an unrelated mission would distort its design. The same risk appears when a product team promises broad capability based on a narrow demonstration.

The product manager’s responsibility

I think about those four machines when a product team has to commit to a design. Somebody will have to live with the consequences long after the launch meeting.

When I look at a product proposal, I want to see how the parts serve the user’s work and which choices could become expensive to reverse. I want the team to explain how the product can adapt when the technology around it changes.

A design decision that seems small during planning can become expensive once customers depend on it. I’d rather ask awkward questions while there is still time to change the plan.