We got a lot of interesting feedback in this first survey!
Here on top I've summarised reponses. On the bottom we have addressed every single question/remark that came up.
64 responses, 40 from sales
Number one and two had the plurality of the replies here. Almost every feature was mentioned at least once.
There seems to be a lack of awareness on what we're building in Plan, this is addressed below, many things that were mentioned are in progress or planned for the near-term future.
No consensus whatsoever, but some highlights:
We now have a separate vision page for each stage in the DevOps lifecycle.
You can find them as
/direction/[name of stage]:
We will take the time to regularly present these in sales meetings, and other occasions that can be easily shared.
On each of the DevOps stage pages linked directly above there is (or shortly will be) section on how we prioritize and make decisions (given that this is not the same for each team).
We will also be repeating this survey every month, and publishing the results here, and in a presentation.
We're looking into ways of gaining more insight from shared SalesForce links. Today, the Create team uses them directly in their RICE scoring, but looking at all links ever shared has revealed them to be a very noisy signal: The majority of issues with salesforce links, only have a single link. There is a handful of outliers that have 10-16 salesforce links, some of which are issues that are scoped too broadly (e.g. integrate with X), whereas others are already being worked on (group merge requests).
We are! You can see our full vision and plans here:
Andreas: We are! We are currently working on a roadmap for 2019. For a high-level perspective on what we want to do, see "What to expect from Geo in the near future" in this recent Geo blog post.
Andreas: We agree. There is a cross-team effort working towards improving activities/todos/notifications, see Merge todos into notifications with pinned and unpinned notification sets. There’s also a dedicated Slack channel: https://gitlab.slack.com/messages/C9CMR2EP4.
Andreas: We agree, and this is planned for 2019. See the epic on Auditing and data management improvements. We will also cover ideas in an upcoming blog post.
Andreas: Agree. I recently added Smart dashboards as 2019 vision. Right now it’s still generic, and I’d love to get further input on what we should work on in 2019 besides personal and project.
Fabio: we are introducing group-level security dashboard that will include data for Directors and CxO.
We're working on this, see our Gitter roadmap.
Andreas: Yes! I think we have an enormous potential here, especially for roles that are very close to the development workflow. Read: Designers, Technical writers. I plan to discover how we can support Designers needs better in our product in 2019. There will be a new product category "Product Design Management" planned for 2019.
Fabio: we want to support security teams as first-class users (e.g., default view to security dashboard)
Jeremy: we’re still immensely reluctant to add fully custom roles to GitLab. It adds a lot of complexity to the product, confuses our documentation, and adds an extra layer of configuration that we still don’t feel is worth the maintenance required. The underlying problem (our permissions framework isn’t flexible enough, esp. For rules-heavy enterprises) still demands a solution:
We’ll continue building out feature-level configuration. This is less risk and we’re able to ship these changes faster.
We’re considering a feature to make feature-level configuration more flexible, called Policies. This would be an EE feature that lets instances restrict what the various roles can do.
We want this as well. We're reevaluating whether we have capacity to work on this in Q4.
We have had conversations with Microsoft about GVFS and are following its development closely. There are a number of considerations that prevent using GVFS in most organizations today even if GitLab supported the GVFS protocol. Namely:
the need to run a custom fork of the Git binary on every client, and
the need to run a file system driver which only exists for Windows.
Most importantly we have higher priorities which are needed by many customers, namely Gitaly HA which is critical to the Cloud Native project, GitLab.com and the horizontal scalability of GitLab. Related to this is the deduplication of objects across fork networks.
Jason: See answer for "We should build more depth" below.
Jason: I was hired as PM for CD, so the organization is taking investment in this seriously, and the work for the 2019 roadmap (and beyond) was just published here. Feedback is of course welcome, and we now have a plan in place where we can go after strategic solutions in the space. Improving our CDRA analyst performance is a big part of this and you can see that reflected in the strategic items in the roadmap.
This is one for customer success!
Definitely agree. We want to deliver a global, performant search for GitLab in 2019, including a command palette for common tasks.
Fabio: there any many technical limitations that actually prevent it to be done, but we want to work on this (see issue)
Fabio: we have a proposal to manage licenses at group-level.
Fabio: we already have Gemnasium as part of our security features for dependency scanning, and we are considering adding more but we also don’t want to provide too many integrations since we are a single application
Andreas: Note, there is also Making auto devops easier / better above.
Talk directly with the product manager of the related DevOps stage. If this doesn't work, reach out directly to Job or Mark.
The Create team is working to significantly improve the depth of support for code reviews and approvals for complex real world situations where there are large changes, multiple rounds of review and more.
Andreas: On the Manage team, we are planning the same. While we are extending our range of product categories in 2019, improving the experience and details of our product is a major part of our plans moving forward.
❤️ More Complete (Minimally Lovable) Features to Solve Complex Problems
V1 feature iterations are how we build software, but at the same time we need to continue to curate those features that have proven their value into complete, lovable features that exceed our users expectations. We will achieve this by growing individual features, solving scalability challenges that larger customers see, and providing intelligent connections between individual features. Doing this lets us solve deeper, more subtle problem sets and - by being focused on real problems our users face - we'll leave the competition behind.
We're working with product marketing on making it easier to provide context. In addition, our new vision pages should go a long into doing this.
Jason: This seems to be mostly answerable using the "We should build more depth" answers above.
Agreed. We're just starting a Growth team that will look at ways we can do this most effectively.
Jason: We also have a responsibility to teach our users, which we do through the release post primarily I think. I bet that support is reading these - if they are finding it lacking, then our users probably are too, and we could work together to ensure both support and our customers (at least who follow the release posts) are both properly up to speed.
Our biggest competitor should be ourselves. If we fail to improve Core or Starter, customers are more likely to pay for a competitor than chose GitLab. The community is a valuable asset to the company and an exclusive focus on Premium and Ultimate will alienate them.
Fabio: considering that we entered this area in late 2018, we are quickly ramping up and we constantly iterate every release to improve our security features. The fact we are already compared to market leaders is a good indicator we are going in the right direction!
Product survey Q&A.md Displaying Product survey Q&A.md.