Pivot and Refatoring

Refactoring is an essential -if not the most critical - skill for many reasons. In the context of a startup, especially.
The lifetime of a startup is determined by how many pivots are left. To increase this number, I have to accelerate the "build-measure-learn" cycle.
Eric Ries in "The Lean Startup" (p 168, bottom):

The company pivoted [...]. On the sufaces the pivot seems quite dramatic in that the company changed its position, its name, and its partner strategy. It even jettisosoned a large propotion of the features it had build. But at its core, a suprising amount stayed the same. 

First of all, here ist the hedgehog concept again:

But at its core, a suprising amount stayed the same.

And here ist the part about refactoring:

It even jettisosoned a large propotion of the features it had build. But at its core, a suprising amount stayed the same. 

The company had factored its work into a structure. That set allowed a set of features in the form of a product. A pivot changed the product (besides other things). Therefore I would have to break up the factoring into its parts and reassemble it.
This seems not like refactoring at first, but I would have to refactor my code in such a way that the change of product becomes trivial.
Mastering refactoring means that the building part in the "build-measure-learn" cycle reduces dramatically and accelerates the cycle. This is especially important when I am on a project for some time. In the beginning, the baggage of features is quite light, and fast-changing is easy. Later not. This is the point where refactoring becomes crucial.