There are several answers here tailored to RTSs, but I wanted to point out something that's universal to the concept of a Minimally Viable Product (MVP).
MVP is a concept that's been around a long time, but became very popular as Agile development took the scene. The concept is quite simple at it's core: it's the smallest product which is "good enough." That's it.
What makes MVP tricky is that it is subjective, and context dependent. If you are working on the last milestones of a military contract, MVP is nothing less than "product passes qual tests." Qualification of your product will involve testing every single one of the requirement laid out for you at the start of the contract (perhaps years ago). Nothing short of that qualifies as MVP.
Early on in a project, MVP is a much lower bar (thank goodness!). However, it is also still subjective. What I think is the minimum product as a developer is very different than that of the product owner, and different still from what the VP of my company may think. You have to pick which actor's perspective you are using when defining a MVP.
The most critical voice, in my opinion, is that of the person managing finite resources: your time and your money. In a corporation, that may be a project leader or someone in finance. It might be a VP. If you're a small indie company, or someone who is writing games solo, that person might be you. But it isn't the normal game developer you. It's the you that closes the coding tools and art software and pulls up Excel to make sure you can pay the bills this month. Its the you that has to weigh the balance between spending another night coding on your little passion project versus going out with friends.
Since we're talking about small MVP's (that's what the video you linked was talking about), we can start to use Agile's approach to the concept. I would phrase it this way:
The MVP for any iteration/sprint/phase is the minimum product which justifies the expenditure of resources in the time spent building that product.
This definition is why the military definition of MVP I used earlier is valid: for them, the only thing which can justify the millions spent on a military contract is a successful product which does everything that was promised. But for you, you might be justifying a week or a month of time. The bar is lower.
So for this, take off your developer cap, put on your suit and tailored pants, and let's talk about what happens next. Developer you finishes putting out a product. What are you going to do with it?
Later in the process, one option will be to ship it -- to make money by releasing the game. And indeed, that is one key definition of MVP that should never be ignored. If a product could be shipped, it is a candidate MVP, because making money justifies a lot of development resources. But early on, you're not going to release it. So the MVP is more nuanced:
In early development, the MVP is the minimum product which permits you to learn something worth the time it took to produce it.
Note: this may not be what you intended to learn. If the thing you learn is "this game is never going to make it, so we should quit now... but damn was it worth our time trying to make it," then you won. You did some work, and felt it was worth your time. On the other hand, if you decide to can the game and you think "damnit, we just wasted how many months of our lives?!?" then that's a strong suggestion that you weren't doing a good job of limiting yourself to MVP. If you were limiting yourself to MVP properly, the past iterations would already have been deemed as paying for themselves -- no regret.
So now we can get to the examples which other people wrote here. These are answers which explore what is the minimum amount you need to learn something. But they all miss one overarching detail: what is your next move?
The MVP depends on what you plan to do with that MVP once it is created. Take Philipp's great answer and bxk21's comment. Philipp's answer argued for two "minigames," one of unit control and one of base building. bxk21 argued that those arne't as important as the time management aspect. So who is right?
That's a trick question. They're both right, in certain environments. Presumably you are about to hand the released MVP to some playtesters to get feedback. What kind of playtesters are you planning to use? Are they RTS pro's? If your playtesters aren't experts at RTSs, then Philipp's answer is probably spot on. You're looking at the small concrete pieces of the game. They will have enough background to be able to comment on those sorts of things.
Now let's say you somehow get playtesters like TLO, Day, or MVP. These are pro level RTS players (or in the case of Day, at least an honorable mention, as I do not believe he plays professionally). If these are your playtesters, then bxk21's opinion is probably the right one. They aren't going to care about the little details about whether you build buildings or whether the buildings build themselves. They're going to care about subtle nuanced thing, like time management and balancability. Now you won't have these sorts of things nailed down in early testing, but you should be able to let the flavor of them show through. You should concentrate on making a game which demonstrates the feel you want the game to portray at a high level of skill.
So figure out what you want your next move to be. What do you want to do with your product. Then figure out what your MVP is with respect to that goal.