This is a nuanced way of looking at the base class and derived classes.
The implication is that you should look at what the derived class (aka subclass) inherits as a sort of contract with the base class. What the base class provides, or doesn't provide, affects how the derived classes can be used and how much work goes into them.
So let's use a base class of "Shape" with the property "Name."
I derive a "Square" and a "Circle" from Shape, and I'm able to use their inherited Name field to set the object's name.
So far, so good.
Now we add an "Area" property and a "GetArea()" method to Shape.
We can code GetArea() within Shape because we simply return the Area property.
But how do we make the shapes calculate their area? We can't write Shape.CalcArea() as we haven't given it any knowledge of the shape's dimensions. So we're obligated to write a CalcArea() routine in each of the derived classes so that Shape.GetArea() doesn't fail. (failure == not producing expected results)
There are ways to solve this through overrides, virtuals, abstracts, etc... based upon the language. But the point of the sentence is to make you think through those relationships.
We need to think things through because we now want to use Shape to derive a class "Cone." Cones don't have an area, they have a volume. And now you're into your class design questions of what should the base class implement, and what should the derived classes implement.
By definition, the derived class can see and access everything that the base class has to offer. In the Shape example, this is a "good thing" and we explicitly want to share everything from the base to the derived class.
But let's say that in Shape v2.0, I need to pre-populate things from a database. So I make Shape derive from a database connection class "DBConn." Now, all of my circles, squares, and cones are database connections as well. Each individual shape has access to all of the database connection information and is potentially now tightly bound to how the DBConn actually works.
So instead of calling Square.myDBConn.Connect(), I can just call Square.Connect(). So if I should ever want to change the implementation of Connect() later on, then I'll need to look at all of the derived shape classes to see what may break with that change.
At it's crux, this is the "Is A ..." vs. "Has A ..." encapsulation question that should always be considered when combining objects.