I was talking to a company that is implementing the Spotify model and needed some help. They wanted to know the difference 
between LeSS and their Spotify model. We first discussed what LeSS is. I told them that LeSS is an organisational design that optimises for shortest lead time, flexibility and learning. What single team Scrum does for a 1 team, LeSS does for whole development organisations.
This answer started an interesting discussion on the difference between between their Spotify model and LeSS. I am not an expert on Spotify model but I understood enough about their implementation to have a good discussion. I briefly summarised the 3 main points of our discussion below:
HUMAN RESOURCES
A possible difference between their Spotify implementation and LeSS is that they have ‘chapter leads’ that have HR responsibility over people in their chapter. So for example they can have a Testing chapter with a lead that has HR responsibility of the testers in that center of excellence; this is a single function organisational element. In LeSS we try to not have such a single function organisational structure. Instead, cross-functional managers that have HR responsibility over cross-functional teams are preferred; this promotes multifunctional-learning and therefor flexibility of your organisation.
CONTINUOUS IMPROVEMENT
Another point is that LeSS is based on Empirical Process Control; there is no model to copy. Copying a model from another organisation is dangerous as contexts differ and it is highly likely that it won’t provide the benefits in another context. The most value is not in copying the model itself, but in the journey of discovering a model that works for you, and all the learning that follows from that.
But even worse is that copying a model will not lead to a feeling of ownership. Ownership is promoted when people create something themselves, and if people feel ownership it is more likely that they will improve it; hence it is a precondition for continuous improvement by the people doing the work. Just copying what other people do, makes it harder to feel ownership. It will be more like renting and that makes a difference. I treat my rented cars different then the cars I own :)
Also, from the perspective of continuous improvement it might not be such a great idea to reach for an end state that you can actually reach; because you might actually get there :) And then what?, what happens when you have implemented the model? are you then done? mission accomplished?
This company understands that and they take continious improvement very seriously.
THE MODEL EMERGES
So, deciding to implement a model a-priori as the end solution is like providing the answer before knowing the question. To me this is kind of silly; don't do that. Instead you can start with the simplest process that works. And then you build it up using Empirical Process Control and a framework that makes transparent to all what to improve; that framework is called Scrum. We like to say that it is better to build your method up instead of tailoring it down. So you add stuff as the need for it emerges.
From what I understood they are doing that and doing it successfully.