More precisely, the query analyzer will only use an index if the first N columns in it are included in the query.
Given indexes (columnA), (columnB), and (columnA, columnB),
SELECT * FROM table WHERE columnA = 123
could use the (columnA) or (columnA, columnB) indexes.
SELECT * FROM table WHERE columnA = 123 AND columnB = 456
could use the (columnA) or (columnB) or (columnA, columnB) indexes - and the last one is probably best.
Note that (columnA) and (columnA, columnB) are redundant: anything that can use the first one could also use the second one.
There's more to it than just about being "common", but that's a decent starting point.
If you wanted to query for products across all orders.
Point #1: An index takes up disk space to store the data.
Point #2: Each index slightly reduces performance when making changes to table data because the system has to update its indexes.
Point #3: (order_id, product_id) and (product_id, order_id) are mostly redundant.
Conclusion: I don't think there's enough reason to create both.
Addendum: Actually it kinda depends on the data. But mostly I'm trying to discourage the "moar indexes moar columns" mentality.