For the multicolumn index, see joanolo's post. I'd like to raise attention to your clustered index however.
A clustered index is the most efficient index a table can have. Since your product code is already unique, you might want to consider making it clustered instead. But there are considerations.
The main reason for why it's usually advised to create a clustered index on an identity column, is because a) a clustered index controls the order of the data on the disk, so you want to have it in a column with an ever increasing value to avoid fragmentation. And b) usually this identity column is also the primary key, which means other tables may contain foreign key references to that field, which means that if it's clustered, all such relational queries perform much faster due to the clustered index not only being the fastest, but also containing all the information of the same row (even other columns on the same row).
The full picture is difficult to explain in short here, I suggest you read up on it more. But basically the point is this:
If you know that you will NOT get many new rows, OR if you know you can handle the fragmentation (by for example using an appropriate compromise with index fillfactor, or reasonably regular index maintenance), OR if you know that from a business logic point of view, the product codes will be added in an ever increasing numerical / alphabetical order which means there will be no fragmentation in the first place... AND if you know that there aren't too many references to the identity column, or that the queries which those references are used for, can handle it... In this case, it might be optimal to create a clustered index on product_code instead, and if required, then place a nonclustered index (primary key or otherwise) on the identity column.
Note, do NOT do any of this unless you know what you're doing. But from an optimizing point of view, I figured it would be good to mention options. Your current setup, with joanolo's suggestions, matches the default recommendations. Anything more, including everything I've said in this post, assumes you have a far more detailed understanding of what's going on, how the data is structured, and used.