Is the V1, V2, V3 [on the public schedule] actually a tiering, rather than a whole version of the feature getting refactored?

Sean, our tech content director, thought of versioning like he should think of versioning. And for this, there's many ways to do it in project management: versioning, tiering, must-haves versus nice-to-haves. There's all kinds of words we use. But a tier one is like, this is the initial implementation that gets some of the very simplest stuff we want, but it's not the end. We're not done. And we're planning out the next two, three, four, five steps, so we understand what can come in. And then we can pull features in. We pull this one up, we push that one out. And that's what ultimately gives us a schedule. And what I wanted to put up here is what you guys saw that we have up on our schedule, and that's some of what got us to this point.

And each one of those features has a whole breakdown like we've just done.

Each one of these parts is that thing we just did, at all different levels, because some of these are per discipline. So when you see one that's just networking, maybe it just has their interdependencies. It doesn't include everything. And then there's sprint planning or feature planning or goal teams, and they're going from start to finish across all teams. So this is trying to give you a semblance of here's our targets per discipline, per pipeline, of what we're trying to achieve this year. And we'll put them in when they make sense.