OK - From what I've understood.

Each Status has a set of common columns, which might include who changed it to that status, when the change happened etc.

These common columns are the same for all the status changes.

So what I would do is to capture is the details of a status change for the object.

So separate those out into a separate table along the lines of

Table ProductStatusChange

ProductId (FK to Product)

StatusType (Either a foreign key to a validation table of acceptable Statuses or the actual Status)

ChangeDate (Date the status was changed to the value above)

Accepted

Rejected

AcceptedBy

AcceptedDate

RejectedBy

RejectedDate

NumRejections

Sent

ExpectedSendDate

SendDate

That will shrink your table some and allow addition of new Statuses.

Things like TimeToCut are actually attributes of the product and should remain keyed by the product.

If there are a significant number of columns that are not frequently accessed then I would consider splitting the Product table into Product and ProductExtension, but only if this would either simplify my life (big tables are a pain) or cut down on I/O (huge text blocks that aren't used much).