 All right, welcome everybody to the weekly marketing call, I guess, or the bi-weekly, as I see it. So this is, I think, my first time joining. So my name is Victor. I'm a product manager here at GitLab. Erica has kindly asked me to chat a little bit about portfolio management features and just have a general discussion here. I think she called it a training. I'd like to think of it as more as a demo and a two-way conversation. So what I'm going to do is just quickly screen share some ideas, some existing features, some things that we're doing in the future. But please, please just interrupt me, just cut me off as it's somewhere in our handbook that we should do, and ask questions or say something is not a good idea, things like that. And we'd rather we have a discussion because everybody can click on the links themselves offline that I provided in the agenda. So my name is Victor. I'm a product manager at GitLab. If you click on the first link there, the products categories page, it has a good number of information there in particular. You can find different product areas within GitLab, and you can see the associated product manager who is responsible. So if you ever have a question about a feature, whether you're using the feature yourself day to day or you want to know how to market a feature, you have an idea, you want to do a blog post on and so forth, that's a great place to figure out who's responsible or what area, as a first pass. And then the next thing you can do is go into Slack the product channel, and I mentioned that particular product manager to get more information. And then as we've been learning from the team call, we should avoid DMs as much as possible. And one point I wanted to add to that, the whole DM is not helpful thing, is not only is it not transparent, and the key about everybody can contribute is true and beneficial and strategic for GitLab, but it's actually very practical for a need that you have. So what I tell a lot of folks to think to me, I say, it's not that I don't want to answer you, but if I'm not here, if I'm on vacation, or maybe you just want to answer right away and I'm sleeping, it's actually better to mention me in a particular public channel. My chances are my boss who's five hours ahead of me can answer your question or maybe another product manager who's several hours ahead of me can answer as well. So it's just faster and more practical in that sense. So again, it's nothing personal when I tell people to not DM me. So jumping to letter B in the agenda, design philosophy, flexibility versus narrow use cases. If you click on that link there, it's some high level information of what GitLab's vision and mission is. And so why I think that's relevant for today is because we're creating all these awesome features for project management and it's going to be used by our customers. It's going to be used by ourselves in the product teams, design teams and engineering teams. But ultimately our goal as GitLab is to have all digital content read right. And so that means can folks use GitLab outside of just that narrow confines of developing software. And so we do that when we do blog posts and we do content marketing when we update our website. A lot of that is not what we call, quote unquote, software engineering day to day. But there's a lot more digital content and processes and work that we do day to day. So at GitLab, our marketing teams use this, our support teams, many non-engineering product teams are using GitLab already, but that's not very unlikely the case for our customers. And we want our customers to do that eventually and it's going to be really hard to do that without, you know, folks, without ourselves first adopting that. So that's why when Erica said, like, okay, you do a little demo or training here for the marketing folks, I said, yes, please, please, because we need folks like yourselves giving us feedback. And another thing I'd like to tell a lot of our folks, GitLabers in particular when they request a feature, I said, yes, please tell us features you want, because it's a low risk, high reward thing. If we make an issue, if we do a feature that we use ourselves, it's low risk because we're guaranteed somebody is going to use it. So it's bound to be a great idea. And it's high reward because somebody's benefiting us. Yes, maybe it's not going to bring in a new deal. But ultimately, there's productivity gains within GitLab. And that is strategic for the organization. So I get the benefit, the curson benefit of working on project management features, a lot of features in GitLab because a lot of my product area is used by all GitLabers. And so that's benefit because I get feedback right away. It's a curse because a lot of people get angry at me, but please continue getting angry at me that your favorite feature is not being worked on yet because we need that constant feedback. So I wanted to talk really quickly about some existing upcoming features. The issue board is something that we're really doing a lot of great innovation on, in my opinion, because we're leveraging the board to do so many things. And so that comes back to letter B, flexible tool versus narrow use cases. Some of the use cases that I'm going to go through really quickly now, if you look at different tools, they have very specific features or UI to do those things. And how we innovate at GitLab is we provide a tool, a single application that can do many, many use cases. And so the strategy here is that we are creating less features, but that cover more use case and solve more solutions. So that's the strategy. So for example, workflow tracking, DI workflow tracking, that's your typical agile board use case, your issues going from in development, development, in UAT and QA and so forth. Letter, double I planning with different categories. That's just a byproduct of how we created issue boards for workflow tracking, not because we use labels for workflow stages, now you can have just regular planning. So if you have lists with different types of labels, you can do that. So that's a great thing. And for, so I'm going to share my screen really quickly here, because I'm going to start showing you some awesome things. For team visibility, that's something that we just shipped. So let me start closing these windows here, our tabs. So this is an example of a team board. And so we actually don't have a team board. And so we say, oh, should we create the cause of a team board and note that that's, again, too narrow of a use case? So we'll just create a sign list. And so people can create a team board if they want. I've seen, I think, in the marketing, I think one of your boards have both a sign list and label list. And that's great. You use it the way that you need to use it. And so for this example here, the platform backend team, the team, the engineering manager, individual contributors, they can quickly see what their, if I'm James, I know what I'm responsible for. Or if I'm James L, I know what James E is responsible for. But if I'm James E, I can also see what James L is responsible for, and also Francisco. And so right away, we've invented team management just by adding one list. And so I'm really excited that, again, we're using a board yet in a different way. What we're working on right now in 11.2 is yet another type of list, a milestone list. So you have 11.0 as a list, 11.1, 11.2. And so then as you're doing milestone planning, you can drag issues across milestones right away. And you can see how many issues, how much weight belongs to a single milestone. And you can drag them over one by one. If a work did not get completed in a previous milestone, you can drag it over. So example in Jira, they have a dedicated vertical view where you drag issues down instead of horizontally. That's a great UI. It's something that we might do in the future. I'm not saying that's a poor feature. With GitLab, instead of spending three months just to present something new and introduce new complexity, what we did is we just took something existing and then we made it more powerful. So that's issue, board assigning lists. And I think that's what I'm calling the milestone list. And that's the fourth way we're using boards. So to me, that's very exciting. Burndowns and analytics. So burndown charts are something that we've had in GitLab for a while. And so this is something, again, that software teams traditionally use. Again, as I said earlier, we want to take these lessons and these processes and see how the other industries or departments can use them. And let's not even say industries, just other departments and how we want to track work, quote, unquote, burning down. And so this has been great. A lot of our customers have been using it. But unfortunately, we haven't been using this view a lot. And so that's a problem. And so we're working really hard to make this usable for ourselves. And so the idea here is that the reason we're not using it, or in particular, the product teams and engineering teams are not using it, is because our teams are not scoped to one milestone. Yes, we standardize them one milestone at 11.2. But the discussion team, excuse me, the platform team, they all share this milestone. And so it doesn't make sense that they're all looking at this burndown chart. And so one thing that we've thought about in the past, oh, can we just filter this burn down chart by label? And then the answer is yes. And so initially we thought, let's do that. Let's build this in here. So that was a consideration. But then we thought, well, what's a better way to do that? What's a better way to do project management in the context of teams? And so again, we went back to the board because that has emerged as an innovation space for team workflows and team use cases inside GitLab. And so the next feature that we're going to be working on, which I'm really, really excited about, is having the burn down chart inside the board itself. So if you look at this, Mark, it doesn't look really spectacular. It's just a regular burn down chart. But what you'll notice in the Chrome at least is that it's actually inside the board here. So the idea is that you're already using a board as a team. So whether you're a backend team at GitLab and whether you're a marketing team that's responsible or you're a crew within the marketing department at GitLab, maybe you're responsible for a particular area. And there's a three-person team doing a specific task. And then you have a board just for yourself. And you want to see those issues burning down. So you've already created a board. You maybe have a workflow. Maybe it's planning. But you've already clicked the Edit button and scoped down your particular milestone issue labels, and so on and so forth. So we've applied, or the design is that we're taking that scope. And let's just apply it automatically to the burn down chart. So you click on the burn down chart here. And then you see the burn down. And the scope is automatically applied. So you don't need to go to a different UI to look at the burn down chart. So that's something that I'm really excited about that we're hoping to ship probably in the next couple of months. So that's burn down charts and boards. Analytics is an area inside GitLab that we've been working very hard over the years, I would say, at GitLab. So we have things like second analytics, contribution analytics, DevOps score, as we're calling it now before it was con depth index. But we're embarking on a new area called ValleyStream Analytics, or at least that's what the industry is calling it, what folks like Forrester have been telling us that it's a mature market and we need to get into. So the idea here with ValleyStream Analytics is something that we've known at GitLab and we've innovated on already for a long time, namely from idea to production or complete DevOps lifecycle as your idea is early on in the ideation stage along the way it becomes requirements, mockups, specifications, and it turns into code. And then the code is review and then it's QAID. And then it's reviewed by product teams, other stakeholders, and then it's the ship to maybe staging and the production and so on and so forth. So the complete DevOps lifecycle. And so the idea here, so I think we have a question, so please just interrupt. Thank you, Elsie, and you can just say you love this and interrupt me. Hi, I'll speak next time. Save me a click, Elsie. So the idea here with the lifecycle is we want to know the time. So we've been innovating a lot and if you look at Psycho Analytics, some of our features we've been saying let's figure out the time it gets you from idea to production. And so the idea with some of the value stream analytics is can we get more insight? Can we know the time from idea to production? But can we also know the time it takes you from to for a QA team to finish this issue? Let us know the stage of development or specifications or maybe in some of these organizations you need to spend like three months doing auditing or of the specs. The technical architecture needs to be reviewed by the enterprise architect for a variety of reasons and you want to quantify all that in terms of time at least and then is there overlap? Can we speed things up? What is the blockers? You've done things for the past 10 months. What is the low hanging fruit of things that we can improve? What are some of the things that the legal team is saying we have to spend this time anyways so we can't short circuit that time? So what are some of the things that Gillab can equip their customers to help with this? And so in talking with some of our party marketing folks, some of you folks on the call, some forester, some of our customers, we've come up with some initial design concepts and we're working really hard actually in this iteration to lay some of the technical groundwork and we hope to actually ship something in 11.3, our first iteration of this so I'm really excited. So I'll show you some initial ideas here. So the idea for example in this particular mock-up it says that for a very simple four stage DevOps life cycle as we might call it, a customer might have these four stages and within the month of February on the average this stage took five days, this stage took six days and in total you know you took 33 days. Over time you can see that in this past half year you've improved significantly. You can see all the, you can even see the relative proportions where you've improved. So right away this is a very valuable view of what time is taking. What's interesting with this as well and something that is new to Gillab say compared to cycle analytics and some of the previous work we've done is that this is totally customizable. The idea here, the innovation here is that we've taken a workflow issue board and you've already determined what stages you want and you click a button and you get a UI similar to this and it tells you what the stages you already care about, the relative times and ratios and how you can do more. So just with this concept and just with these basic building blocks you can dig deeper. So let me finish up with this issue and then I'll look at the chat again. And so this is another similar view and so you can see here, I've just you know graphed it sort of a different way you know flip those X and Y axes and I've also segregated or separated two sets of labels. So from here you can see this top line is the useful work and this is the bottom line is the wasteful work. So say your QAT went off to a offsite summit for two weeks and they totally didn't you know sync up with the rest of the organization so that's not a good thing and there was poor planning and then so the engineering manager, the director can look at this after the fact and say oh why do we have this anomaly and go back and adjust that after the fact. So that's a great thing. So again this is something that Forrester have told us that the industry is looking forward to and something that we've verified when we talked to our customers that they're interested in just seeing that separation of useful work versus what they're calling waste and so something that we can do with GitLab. And this is just the same thing but stacked together and so you can see the relative ratios and then this is probably my favorite one here which is allows you to drill down and so the previous screen showed you the relative proportions and so this will show you say now that you've identified QA is a problem so let's drill down just to the QA stage so this view is just gonna show me the QA times and instead of showing just the average which is this purple line chart within these months let's actually graph all the issues that occurred in the month of January, February, March and let's look at the actual times on this Y axis so this one actually be average time will be the purple but these are the actual times so now you can see the average at a glance you can see visually the distribution and so you can see in the month of February everything is concentrated around the average that's good and low uncertainty. In March you can see wow there's three outliers what happened here and so if you're concerned about this as an engineering manager or maybe you're a director and you're in charge of three teams and so any of these can be scoped to any granularity teams number of issues and so forth let's say you're the engineering manager and you wanna really know what happened with these three issues why there's three outliers you take your mouse you just click on that button or you mouse over it and you see the issue you click on it and you go to the issue itself and you can see through the comments you click on the merger class you can see what went wrong so this is back to the power so it sounds like I'm selling GitLab to GitLabers but GitLab is the single application we have the entire stack we have the entire application everything is integrated so as we build analytics we have we're cheating we have everything we have all the information so I can mouse over the issue and I can go directly and find out what's wrong. Hey Victor I just have to say I love this I am jealous of Cindy who is doing the 11.3 release pose we'll get to write about this because this is just really cool. Right, right, right definitely William. So yeah that's precisely right so 11.3 I don't think we can get this entire screen I at least want to get the black dots it may be the purple line getting this might be a little bit hard but at GitLab we move really really quickly and I really want to get something on the screen into GitLab so that's exciting. So the rest I don't want to take too much time I already took 20 minutes so subgroups list milestones and labels these are the bread and butter the basic concepts of GitLab and we continue to use them and so subgroups is something that customers have been asking for and in terms of project management just that additional structure is super important so do read up on the docs and look at relevant issues but I don't want to spend too much time there multiple milestones per issue again that's something that customers have been asking for and it's basically a blind spot for GitLab because our milestones and our releases they're the same thing 11.2 is an iteration that we work on GitLab for the month but it's also the release and for some customers they might work on five releases for five iterations worth of work and then release it all at once so they want a separate field to do that and so from project management perspective that makes a lot of sense it's very critical something that we want. Portfolio management is a brand new area that we worked on pretty much more than half a year now we launched our first iteration of EPICS and road maps or the thing just EPICS back I think in November or October of last year and so we've been moving really really quickly and I'm really excited because things have just gelled together and really as we've developed it as we've been using the features inside the product teams and the engineering teams we see how these things come together and our customers are saying oh this is pretty awesome I want this and with the other ultimate and gold offerings they're starting to pick up this work so again it's really strategic for us to use it and then once we have that level of feature and functionality our customers are using it and so the idea here is that we started first when we developed this feature top-down planning and tracking and creating EPICS and road maps and it wasn't the best of idea because we weren't really focused on our own use cases but that's a different story I don't have time to get into but the idea with EPICS and road maps or EPICS in general EPICS are for if you look at EPICS right now you can assign a start date and an end date and assign issues to the EPICS issues and milestones are separate and then you know there's a connection that I just mentioned but if you look at EPICS there's no milestone assigned to an EPICS and you might think that's weird and so there's a little bit there's purpose to that so if you look at this screen here you can see that as a product manager these are the EPICS I'm responsible for but a lot of these far-off EPICS in the future I don't actually know what issues are going to be part of them I know just a general idea and I know I want to start working on them in 2019 Q3 really far away and I don't know if customers care about them I don't know if they're good ideas but they're strategic you know I've talked to analysts I've talked to customers that they want this general concept so this is top-down planning these big ideas far into the future I care about and so at GitLab we don't have the tools and we don't actually do that very well just yet and EPICS and road maps right now can actually support that use case fairly well you have an object called an EPIC you have a start date and end date and you just plop it on away you go what we can't do right now and what I'm anxious to be able to shift in 11.2 is bottoms-up planning so bottoms-up planning here what that means is that again with this view with exactly the same view I'm sorry I'm jumping around but now it's not far off in the future but it's say this EPIC that we're working on right now and we're actually going to be done and so with this EPIC there's probably 10 issues assigned to this EPIC there's probably five I think and the issues have milestones associated with them already so I actually don't want to set a start date and end date or actually I want to replace the originally start date and end date that is set half a year ago with the ones that are automatically inherited by the issue milestones themselves and so that's exactly what we're building in 11.2 and that's exactly what our product folks have been asking for because we do a lot more bottoms-up planning at Gillab versus top-down planning and so I'm really excited because I'm pretty confident that we'll be using a lot more EPICs and roadmaps once this feature ships and namely once you see this roadmap you will be able to say for a given EPIC I want to use the automatic inherit milestone start and end date mode versus the far off into the future top-down I don't know what issue but I know the approximate start date and end date of that EPIC mode and so these are two separate modes that will be independently set per EPIC so that's what I want to differentiate between top-down and bottoms-up and finally this is really far off into the future but something I'm uber-uber excited about boardless capacity, capacity planning and roadmaps something we don't do at Gillab even on the product teams but something that we're ramping up with engineering management becoming a thing with director level and just more engineering being more of a discipline at Gillab and so the idea with boardless capacity here is that now you can set actually a capacity per list so what I showed you earlier with the mouse on this you can actually set a capacity per list and so engineer managers can go there and set a number and so this might seem like pretty trivial okay you just add a number that's not much but it turns out this if you think about long enough and I don't want to take more time but this will and you know I've talked to some engineer managers and they would find this useful and at a glance you would be able to see okay you know in the 11.3 milestone I have you know space for 50 weight but I've assigned 120 weight that's too much what can we do and you know everybody has visibility to that taking the same exact concept applying it to the roadmap I think I really love this idea I'll show this to a couple of folks who are excited about this can we do the same thing with capacity on the roadmap view probably I don't know how that would look that would be really confusing the first innovation here is that we're just gonna sum up the weights of the capacity oh sorry of the issues so take a given epic here from July to December divided uniformly say that there's 10 issues that the sum of the weights is you know 100 divided by five months it's gonna be 20 each and so it's gonna be 20 here 20 here 20 here 20 here and then add up all the ones vertically and you get a graph and you get a number here so boom right away you're looking at the roadmap view and you can product managers like me is uber ambitions and say I want everything to be done in the quarter three of 2018 and then you know Sean my counterpart on the backend engineering side says no no no Victor you're crazy because I've already estimated all these issues and weights and this is like 300 and we only ship like 50 per month and so this would be super useful for him super useful for me super useful for his manager for Sid, for Eric, for Yo, for Mark and you know the senior executive team because they can see really far into the future they can see a graph like this and they can see oh this is really really important I want this I can't get it let's hire more people so those conversations I'm really excited that we can start having with a view like this. So thank you for entertaining me for 26 minutes that's awesome that's cool okay yeah great so sorry Eric I didn't know how much time I was allotted I wanted to finish like in 15 minutes but I went way over but I'll take questions or somebody can cut me off and tell me to run away so you can talk about other topics but please shoot questions. Question Victor. So it seems like the app because right now I'm using like I think the marketing team is using issues like we have meta issues to kind of do an overview of the rest of the smaller issues kind of like subtasks so would that epic be kind of a replacement of that like meta issue? So it's easy to look at the hierarchy of the issues. Yes Agnes that's one of the uses we wanted to do with epics and so there's the answer is yes and no so from a design perspective that's where we're heading toward where an epic is a collection of issues that are related in feature and content but not necessarily worked on like you know in the next five milestones together in succession so they're related together in features so notice we haven't associated a milestone or even a group of milestones per epic we might do it in the future but it's not something we're doing right now so yes that's the intention and from a use case perspective it's just a nice placeholder it's something that wraps on top but from a use case perspective as you're using it now what I would recommend is look at what you need and say like oh epics doesn't support that yet and I can't use it and then or what I would love you for folks to do is to take the jump and start using epics and then start creating issues and features and saying I really need this feature Victor can you please please please create it so that's what we want to do so usually when people ask me should I use epic for this I say yes please but I don't want to make your life terrible at the same time so the idea is yes you should but realistically it's the same reason when people say like I'm still using Google Sheets to do planning I'm never going to yell at somebody too that they're doing that I just sulk in a corner when somebody's using Google Sheets to do planning because I haven't solved their use cases yet so when that happens I say please share that Google Sheet with me and we'll create the features to make sure you can move off of Google Sheets and so we'll create the features so that you can move off of meta issues because that's not what we want to do Joyce you said how do you switch from epic to top and bottoms up and so the idea here is that we'll just have a toggle or we're creating it right now and so that's exactly here I'll just show it here so you get to choose the start date whether you want to use the fixed version or the inherited version as we're calling it and then by default it will be the inherited version which makes sense because when you create an epic there's no date set so say you create an epic and start assigning issues on it so it'll automatically inherit and then but if you did want to set a manual date you would do so and then you would click and but by that time you can override it so that's how you would switch quote unquote switch the modes and so it's actually more granular per epic it's actually per date per epic Thank you Any other questions, comments, bye Hey Victor so it seems to me that the most benefit teams would see or teams of teams would see is really just going to be unlocked when kind of across the teams people are using issues and epics and related features consistently I was wondering if you could share anything from product or engineering in terms of what has worked well to kind of establish the consistent usage across the teams So you're asking like how ourselves our process is using these features is that or maybe like and anything that has been useful in driving consistent usage across many people across many teams Yeah, yeah, and I can probably guess why you're asking that as a scaling organization at GitLab and we're growing so I'm missing a product team call right now and they're probably arguing about some new process or change or something that they want to make things better and so yes, we have struggles and stuff like that with getting things consistent so I can share some things with you for example, label usage is something that we use a lot with and the reason we use labels is we can always use because labels are so versatile and so useful it's always the first thing we go to because we haven't created a new native feature to support that particular process yet and so for example we want to track miss deliverables within our organization as an OKR for the engineering team and so the way we're going to do that is we're going to have a bot that's going to crawl all the issues and then look at after the code freeze if you miss the deliverable put a label on it and then maybe put two, three labels on it and so we can track those labels over time and we can say 11.3, you know, X percent was missed and stuff like that so that's an example where we need a consistent process and we're trying to use automation to make it easier as well as consistent because bots don't make mistakes in terms of consistency and because the feature that we're building will take maybe three or four more months and so the feature we're going to build is similar to what I showed earlier with analytics we would actually the latest idea I have is that we're actually going to use the burn down chart and you're going to filter the burn down chart on miss deliverables the burn down chart is going to be historically accurate and so you can look at the burn down chart and see how many things were planned at the beginning and how many things were shipped at the end and you get a number so that's the feature that's going to solve that problem for GitLab but that's the feature that is not going to be shipped for at least maybe three, four months so how do we solve the interim? We do quote-unquote hacks around the thing like that and another example is like using just using epics and issues ourselves and then the example Agnes had or the question Agnes had with should epics replace meta issues and maybe we're doing that I would say 80% of the time folks are not using meta issues anywhere and using epics but still that's not always 100% of the case so we are having some and so how we quote-unquote solve the consistent C issue is that you know we standardize we have a meeting you know we have a handbook probably same as the marketing team I would imagine Makes sense Thanks Victor Definitely So yeah so again I encourage everybody to just ping the product channel even better ping myself in an issue at mention me in an issue at mention me in a product channel if you have any ideas and we'll go from there and I'll stop and share my screen and give the mic to somebody else and I'll I will see everybody Thanks Thanks Victor for presenting Definitely Thanks