What if another property will be added and become optional?
I have done precisely this when I needed to inject some new functionality into that method. This does not break existing code; you gotta love that! In my case I bypass the new thing if the parameter is null.
I generally prefer to use a more meaningfully named value/enum. For example, "Unassigned/Unknown/NotSet".
I strongly disagree with this (quote from a comment). Doing this with a string is a big hassle - typos, casing, lack of type checking (I do C#). However if this was an enum then absolutely, have a "undefined" enum value (in C# I would have this correspond to zero because that's the default for enums).
Should I use null object pattern?
Not exactly. We're dealing with a single property, but the idea is the same. Make the optional/default method parameters behave benignly. For example, I set my optional string parameters to string.Empty (C#) so calling members on it does not blow up.
Should I use strategy pattern maybe? Should I maybe ...
No. Strategy is for polymorphic behavior - i.e. functions/methods with the same parameters (signature) on different types.
Optional parameters is a technique for creating concise method overloads.
I'll have Product and ProductWithColor
Well, if your design calls for that but I suspect not. Why are you letting a single optional parameter for a single function drive your design? null has "special handling required", sure, but so would any property with any value that had special meaning. Here it is just a mechanism for allowing client code to ignore color for the call. How is this a whole different class?