At the start of the article he lists some distinct components that make up the design pattern; mainly they are the Factory Method, an Abstract Product, a Concrete Product, and the Client.
Use the Factory Method pattern when there is a need to decouple a client from a
particular product that it uses. Use the Factory Method to relieve a client of
responsibility for creating and configuring instances of a product.
The word "product" is referring to objects that are /produced/ by the Factory and used by the caller (client). The client could just create these objects directly, but it would be responsible for knowing the specific object type and implementation details (the "Concrete Product"), coupling the caller to that code.
To "relieve a client of [that] responsibility" we'll introduce an abstract class or interface (the "Abstract Product") that is implemented by each "Concrete Product". The factory method will return this abstract type, and the client will call the factory method to create the objects it needs. The client is now decoupled from any specific implementation and only needs to know about the abstract type (and its factory).
The factory method is "responsible for creating and configuring instances of a product". It knows about the various implementations of the abstract type, and can create and return any one of those implementations to the client. The caller does not need to care which "concrete product" it receives, only that its dealing with a given abstract type.
Using a factory method, we can change implementation details (adding or modifying "concrete products" to our factory) without needing to change the implementation of the client itself, and without coupling the client to "a particular product".
