 Thanks Bianca. So we've heard some great news about the company and an update on where the product is currently at, so let's look towards the future and talk a bit about where we're going. We already have an amazing product that covers the entire DevOps lifecycle with a single application, and customers are loving the new scope and where the product is going. So we're going to double down on what's working. We're not talking about radical changes here, our strategy going forward can be summed up with three things. Depth, breadth and roles. And I'll talk a little bit about each. GitLab already covers all the stages of the DevOps lifecycle, but not all the stages are at the same level of development. People love our source code management, of course, and I always hear people raving about our continuous integration or CI. But some of the new areas are still early. Some are even just first iterations or what we call minimum viable changes. So one big focus for us is to increase the depth of these features. We need to go from viable to actually being used regularly to, dare I say, lovable. The idea of a minimum lovable product is a strong one. Of course, in our case, we have one product, so we need a minimum lovable feature. It's great to experiment with minimal changes, learn from real usage and iterate quickly. That's a core value at GitLab and many other companies. It's a key to delivering value to customers quickly. But we don't stop at viable. We keep improving and listening to customers. And better yet, collaboratively collaborating directly with customers to co-develop what they need together. And in this way, we can get to where people truly love using all parts of GitLab across the entire DevOps lifecycle. Now, source code management and CI are good examples where we're already leaders in the market. In 2019, we plan to become leaders in four new areas. Specifically, that's project management. That's things like issue tracking and issue boards, competition for Trello and JIRA. And then continuous delivery and release automation. And that's continuing to invest in deploying to communities but really helping everyone automate their delivery and release processes. And application security testing, which we've added so much to in the last year with static and dynamic application security testing, dynamic or dependency scanning, et cetera. So continuing to invest in all those areas and more. And a new category for us called value stream management, which might be new to a lot of you. So I'll expand on that a little bit later. Now, increasing the depth of the product is great. But we wouldn't be true to our ambition if we stopped there. We're also going to spend a lot of time increasing our breadth with each stage of the DevOps lifecycle. The best way to sum up the breadth we're going to cover is by showing you the new categories we're going to enable. But there are so many new categories that I really can't go into detail for each one. So I'm just going to talk about three flows that give you a taste of where we're going. The first flow is from the executive perspective. It makes use of a new area we're calling value stream management. Okay, we didn't invent the term. It's been around for a long time as part of the original lean manufacturing movement. But it's only relatively recently that value stream management has come to software development. For some of you, this might be immediately interesting. But I know a lot of modern development teams out there are probably skeptical. So let me tell you why I'm really excited about value stream management. At its heart, it's about understanding your team's work and their workflow on their way to delivering value to customers. That can't be bad, right? But what's great about how we're approaching it is that we're really extending something development teams are already using to track their work, namely issue boards, and saying, well, instead of just tracking your slice of the work, how about if we had a board that covered the entire workflow necessary to get ideas into production? And since GitLab covers that entire scope, we can actually automate all of this. For example, we know when you deploy your code to production, so we can move the card to the right spot automatically. So not only can you track your progress and communicate with your team, you can track it all automatically and more accurately. And then because these things are tracked across the entire organization automatically, executives can not only follow along, but they can look at some aggregate information and analytics on it. Here I'm showing a situation where someone was able to dive into the time spent on various areas and see that the time spent waiting for someone to do code review was really high. And they managed to shave off a few days by rearranging some internal process. Same thing for the QA cycle. The net result is right up top that the cycle time dropped by 15%, which means you're delivering value to customers faster. The second flow is an operations one. Here's a new product category for incident management. We monitor your production apps and detect an anomaly, then alert you and start an incident. Then in one place, you can see what triggered the alert, who's involved in responding, and quick links to the Slack conversation, Zoom call, et cetera. And of course, a record of all activity on the timeline. Here it's not just operations people using this tool, but it's part of the same application that developers are using. So when you're talking about problems, you're looking at the same data. And GitLab knows not only what metrics are alerting, but what code was recently deployed that might have affected it, and who was behind that code. One really interesting link on here is the recommended runbook, which we picked for you automatically. Here we envision an interactive runbook based on Jupyter notebooks that helps responders deal with incidents by not only providing instructions for things to investigate, but providing the actual commands to run that you can run right within the page and see and share the results. We didn't invent the runbook, but we're going to make them so powerful and easy that every team will use them. And when the incident is resolved, follow up with your users with a postmortem, pulling in all the relevant data and timeline of events. And of course, with all that data comes great power for analytics. So let's help the team learn from it and improve. The last flow is about security, which we know is really important to a lot of our customers. So here's a flow where instead of making developers and security teams do all the repetitive but necessary security work to keep project dependencies updated when there are new vulnerabilities discovered, we want to automate all of that away. Here, a bot detects the dependency has a new version, and instead of alerting someone, automatically creates a merge request and runs the test suite to make sure that everything still works. If all looks good and confirms that the security vulnerability is gone, so the bot automatically merges the changes. If all goes well, your security and development teams just get an email in the morning saying that it was automatically fixed. But to bring it full circle, after merging, this CICD pipeline started deploying automatically to production. I mean, why leave a known fixable security vulnerability live any longer than it needs to, right? In this case, even though all tests pass, we actually saw the air rate jump to more than 5%. So we automatically stopped the rollout process and went ahead and rolled back to the last known good version immediately. Then the bot detects this and automatically reverts the chain, the merge request, so that we can leave master in a good state. Thus, we can finally alert the teams about. But instead of having to manually test 20 projects, you can focus on the few that can't be automated. The last prong of our product strategy is to expand the roles or the people we design for. We already went from focusing on developers as recently as a couple years ago to talking about DevOps, which of course is developers and operations. But for us, DevOps isn't just about developers and operations. Security is playing a critical role these days. And of course, there's the business side with project management and even executive visibility and reporting. But rather than call that biz dev sec ops, it's just DevOps. And of course, we cover all these roles within a single application so everyone can work concurrently. But are those the only roles involved in software development and delivery? Of course not. There's designers and product managers, maybe even legal gets involved in license review. Remember, our mission is everyone can contribute. We're building on strengths and going through an ever expanding DevOps lifecycle from designers to operations, everyone working in a single product that is either best in class or getting there quickly.