Getting started

1. Create a Google Doc and name the file [INITIALS_OF_FIRST_PERSON]-[INITIALS_OF_SECOND_PERSON] 1-1.

   • For example, if Bob Adrian Jones is meeting with Jen Tai Yin Lee, the title of the file would be BAJ-JTL 1-1.

   • Use three letter initials when possible since there may be people with the same initials.

2. Share the file with the other person, using the Share option in the Google Doc.

3. Create a Direct Message channel in Mattermost and add the other person.

4. Add a link to the Google Doc at the top of the Direct Message channel by editing the header of the channel. Choose Edit Header and paste the link.

5. Use the file for 1-1s to post material in advance and to write notes of your discussions.

Mattermost, Inc. is a company based on the Mattermost open source project, which is a messaging collaboration platform for team communication across mobile, web, and PC with instant search, continuous archiving, and unlimited integrations. Mattermost software is used by thousands of organizations around the world in 16 languages.

What we do: Mattermost, Inc. helps solve collaboration challenges for developers, operators & security teams so organizations can focus on business-critical tasks.

Who we serve: Our Ideal Customer Profile (“ICP”) is an enterprise, defense or governmental organization with 2,500+ employees in need of a collaboration platform for mission critical work that meets complex requirements for security, compliance and self-sovereignty. ICP organizations have significant in-house Dev/Sec/Ops talent and the ability to deploy and secure self-managed infrastructure.

We believe that mission critical work is hampered by one or more of the following;

• Risk from non-compliance

• End of Life of existing systems

• Lack of resilience at scale during infrastructure failure or breach

• Competitive Risk

• Need to preserve sovereignty

• Noise/gaps of MS Teams/general collab tools for tech/operational orgs

• Risk from gaps in Mattermost Team Edition for large organizations

• Low efficiency, high delay and error rates due to inflexible platform

• Need interconnect outside of AD domains and CAC systems

What we offer: Mattermost is a secure collaboration platform for accelerating mission critical work in complex environments. We connect teams, tools and processes on a self-sovereign hub with workflow, integrations, real-time messaging, voice, screen share and federation to deliver more focused, adaptable and resilient decision cycles and outcomes.

Mission

Mattermost’s mission is to make the world safer and more productive by developing and delivering secure, open source collaboration software.

Leadership Principles

Leadership principles are deliberate choices defining our behavior. When facing complexity, uncertainty, or ambiguity (CUA) we determine our point of view and our actions through the lens of our values:

• Customer Obsession: We exist to make customers successful. In everything we do, start with customer perspective and work backwards. Earn and keep their trust.

• Ownership: Own the outcomes of your activity. Don’t drop the ball. When we see a vacuum on something important, we jump in – we never say “it’s not my job.”

• High Impact: Align work to our shared vision and focus on those priorities. When deciding to work on low impact or high impact projects, choose high impact.

• Self-Awareness: We understand and seek to understand our strengths and growth opportunities, as individuals and organizations. We are open to critique and share critique constructively and respectfully.

• Earn Trust: Make decisions based on maximizing the trust of others in your judgement. Be open, self-critical, and factual. Earn and keep peoples' trust.

Market

We see a $30B+ market opportunity in the secure collaboration space and the growth of “open source collaboration” accelerating vs proprietary solutions. Open source has already commoditized operating systems, databases, tooling, and virtualization infrastructure. We see the entry of open source into the application layer driving fast adoption of a new generation of open source and open core solutions, inherently more flexible, trustworthy, and economical than past models.

Products and Business Model

Mattermost, Inc is a commercial open source company with a subscription-based, buyer-based open core licensing model.

For more information, see our Product Overview and open source repository at https://github.com/mattermost/.

Company

Mattermost is an open source, remote-first, communities-centered company based in Palo Alto, California and headquartered on the internet.

Open source means that by default we make our technology, business process and source code available to the public. We develop a small portion as proprietary technology, built upon our open source work, to license for subscription fees that enable more high quality open source work to be produced. Since the start of the Mattermost open source project in 2015, we have used this model to develop effective open source solutions for the world to use. This model is sometimes called Thin Open Core.

Remote-first means that the majority of our staff works from home, cottages, coffee shops and other personal areas, rather than at a shared corporate office location. Mattermost was born in an extraordinary age where remote-first organizations can attract, hire and enable remote teams to produce better technology, business process and business results in less time than office-based teams, while maintaining security and compliance standards.

Remote-first culture flourishes when we share one simple principle: Courtesy. Courtesy means Mattermosters are thoughtful about keeping our communities appropriately informed, following etiquette for discussions, calls and video meetings, and giving and receiving feedback on how to work better together. Courtesy also means we gladly accommodate those who prefer to work out of a dedicated office. We are remote-first, not remote-only.

Communities-centered means we define our success in the context of the success of our communities: users, customers, implementers, resellers, technology partners, contributors, and colleagues. The success of each community is owned by a member of the Mattermost leadership team. The plural definition of “communities” is intended to avoid unconsciously marginalizing downstream stakeholders.

Based in Palo Alto, California and headquartered on the internet means the mailing address for Mattermost, Inc. is in Palo Alto, California, and our headquarters is on the internet, specifically the production-quality Mattermost instance at https://community.mattermost.com. Our online headquarters is where Mattermost staff work with our communities of colleagues, users, partners, customers, candidates, contributors, and other community members to envision, develop, and refine new open source technologies to make the world safer and more productive.

Logo

See brand guidelines for usage guidance.

The Mattermost Handbook is a continual work-in-progress for Mattermost staff (people who are paid to work on our open source software), contributor community, and end user community. We use it to document the processes that underpin our company behind our software. Its purpose is to iteratively increase clarity for Mattermost staff and community co-building the future of our company and our offerings, and provide a single-source of truth.

Early in our history, when we were a much smaller company, our staff handbook was included in our product documentation. Now the Handbook lives in the the dedicated repository at https://github.com/mattermost/mattermost-handbook which is edited using GitBook as a frontend.

Want to contribute to the Handbook? Start here: How to update the Handbook.

All documentation is available under the terms of a Creative Commons License.

Some norms you'll see here in the Handbook:

Growing companies are a work-in-progress

It's Day 1 at Mattermost. We're a growing company and growing open source project out to support the massive transformation underway as open source software unlocks the massive potential of people and teams around the world. As an open source company we like to share early. Sharing ideas early gets us feedback sooner, so we can iterate faster, so we can better results.

On some pages, you'll see reference to 1% and 50% drafts. This is used to express how complete our thinking is around the published content, and indicate whether fundamental changes may be made.

When a section of the handbook is at less than the 50% draft stage you should see it labeled in the page description with the % draft status. When a section doesn't have a % draft status, assume it's over the 50% draft stage.

We believe this system has two key benefits:

1. Be more open to feedback and iteration: Having something published publicly can make it seem overly "final". By having pages in our handbook at 1% and 50% we make it easier to go through feedback and iteration cycles.

2. Engage more non-technical people in the discussion: In the past, we've done reviews largely in GitHub pull requests, which is friendly and familiar for technical team members, but more difficult for others. Sharing 1% and 50% drafts in the public for feedback makes our process more inclusive.

There are trade-offs as well: There may be confusion among people who haven't been onboarded into the 1%, 50% draft concept. People who aren't comfortable with the level of early sharing may feel upset. For these reasons, this page itself is only a 10% draft, so opinions can be expressed and discussed.

Sharing feedback and updating the handbook

Feedback on this handbook is immensely appreciated. There are two ways you can share your feedback:

1. You can create an issue in the Handbook repository. Select New issue, and provide as much detail as possible in the issue. Screenshots and links are also welcome. Choose Submit new issue. The Handbook channel receives a notification and this begins the cycle of feedback and iteration. While not all feedback will result in an update to the handbook, we definitely want to hear everyone's opinion.

2. You can edit the page directly, and submit your feedback/suggested changes as a Pull Request (PR). PRs go through the same cycle of feedback and iteration. The only difference is that an issue is not an immediate change and may take longer to action. A PR already contains the changes, and has a quicker turnaround time. Learn how to update this handbook through GitHub for detailed steps.

Key links and materials

Below is a work-in-progress list of key documents and channels at Mattermost. The symbol * indicates material internal to Mattermost staff.

• Mattermost 9.0 Launch Announcement

  • Newsroom

  • Message House*

  • Product Onboarding*

Vision

Our vision is becoming the leading solution for developer collaboration through an integrated suite of open core tools that accelerate developer productivity, increase software service levels, and raise workplace satisfaction among technical teams.

As the world moves more digital and remote, technical organizations face mounting challenges: stagnating productivity, increasing exposure to outages and service-level degradations, and declining workplace satisfaction leading to staffing churn and expanding talent gaps.

We solve these issues for customers by developing and delivering an open, flexible, developer-focused collaboration suite competing against both point solutions (Slack, Asana/Trello/Notion, WebEx/Zoom/Loom, RunDeck/Transposit/Firehydrant, Confluence/GitHuge Pages) and general-purpose collaboration suites (Microsoft Teams/Office, G Suite).

We deliver our solutions through an open core, product-led growth motion with freemium offerings that flow into usage and conversion from free-to-paid supported by Mattermost champions in customer accounts, frictionless self-serve purchase experience on both cloud and self-hosted instances, and both direct fulfillment and channel-based fulfillment depending on customer preferences and our ability to provide regional support. This motion is accelerated through our BDR and field sales motions with warm outbound into our freemium install base, plus cold outbound into named enterprise accounts driving awareness of the ROI of Mattermost solutions from like customers.

Market

Analysts project that in 2022, over $4.5 trillion USD will be spent on IT. What portion of that investment turns into productivity and results depends entirely on how well teams of software builders and operators can effectively collaborate.

Mattermost competes in a $15B market for "developer collaboration", a segment of the broader general collaboration market focused on accelerating developer productivity through agile workflows across application development, digital operations and security operations. Our focus is serving a market of 30 million developers with an integrated, open core collaboration suite across workplace messaging, project management, incident management, real time communication, and documentation available both in cloud and as a self-hosted component of an organization's digital infrastructure.

Many of these organizations are facing three critical challenges:

Flat or declining developer productivity in post-remote environments. While many technical organizations accelerated productivity in the initial move to remote work--decreasing commute time, onsite logistics, and interruptions--many post-remote environments now suffer from gaps in clarity and alignment that in-office environments provided in the past. The context created by in-person meetings, hallway conversations, war rooms--and even by physical whiteboards and post-it notes--continues to degrade in many organizations. Digital substitutes across meeting organization, note taking, workplace messaging, incident response, and project management have exploded as point solutions. They served as life rafts during the pandemic, but the misfit of teams, tools and workflows is now becoming an overwhelming tax--copy and pasting, inconsistent formatting, unclear access controls, redundancy of information, and the breakage of flow.

Increasing complexity, vendor lock-in and outage exposure. In many organizations the acceleration to cloud has dramatically increased vendor-dependency, data lock-in, and exposure to the business disruption. In some cases, there is risk of both a company’s technical infrastructure and online collaboration tools going down at the same time when they are outsourced to the same vendor, or share dependencies--especially cloud dependencies. These risks may be dramatically heightened with remote work if incident response teams don’t have either a secure physical location to work on mitigations, or online collaboration tools independent of the underlying outage. Moreover, as cloud vendors control more and more of their customer’s data and operations, businesses have fewer options to hold vendors accountable.

Gaps in workplace satisfaction for technical talent. Acceleration in remote hiring coupled with a surge in global demand has made staffing developer organizations an unprecedented challenge. Workplace satisfaction is now more important than ever as a leading indicator of organizational success. Satisfaction includes both conceptual factors, such as opportunities for impact, connection and growth, and concrete factors such as the technologies and tools teams get to operate. Winning on workplace satisfaction in conceptual and concrete factors is a leading indicator of meeting the capacity needs of digital operations organizations, which is a leading factor to market relevance.

Business model

Mattermost uses a buyer-based open core business model to deliver a high trust, self-managed messaging platform for developers and high security end users. We develop a portfolio of offerings at different price points (including free/open source) that align to the needs and budgets of different buyers.

Mattermost Free / open source

The free/open source version of Mattermost is built for developers as an innovative, flexible, high trust collaboration platform that accelerates the productivity and agile workflows of a tight-knit team, and includes the following capabilities:

Channels

(Workplace Messaging) - An open source alternative to Slack, with Slack-compatible keyboard shortcuts and Slack-compatible webhooks, along with a layered extensibility model ranging from plug-ins to custom applications.

Boards

(Work Management) - An open source alternative to Trello, Notion, Asana, Jira and Todoist, deeply integrated with Channels, with the ability to import from other systems, to use and create custom templates and workflows, and to integrate deeply with the rest of the Mattermost collaboration platform.

Playbooks

(Incident Management) - An open source alternative to Rundeck, Firehydrant, Transposit, and other incident management solutions for standardizing and running incident management escalations, remediations, and timeline-based retrospectives deeply integrated with access controls and real-time workplace messaging and notification experiences on the Mattermost platform.

For our self-hosting community, we have an open source Mattermost Team Edition available as a Linux Binary under MIT license that deploys with MySQL or PostgreSQL and optionally a web-proxy such as NGNIX. There's a single-node local machine "Preview" mode you can use to try out the features using Docker, along with a streamlined omnibus version you can use to get a production system up and running quickly on an Ubuntu-compatible Linux distribution.

For our cloud community, our "Free" offering is currently a hosted version of the open source Mattermost Team Edition available on demand from Mattermost.com with unlimited users and a flat rate hosting cost of $149/year. While the software is free, we currently do need to pay for hosting costs in this cloud offering, however we also have plans to provide a fully free offering in future subsidized by revenues from paid versions of Mattermost through our open core model.

Mattermost Professional

Our entry-level paid version, Mattermost Professional, is built for team managers - commonly managers of managers - who need additional controls and workflows specific to multi-team coordination. This version can be purchased via self-service, through resellers, or - for accounts over a certain size in certain territories - transacted through our sales team.

Mattermost Enterprise

As usage of Mattermost grows, we have a high scale edition, Mattermost Enterprise, providing enterprise compliance features and high scale support, including self-managed, multi-node, high availability configurations.

Customer journey

Our customer journey starts developers and IT admins seeking better collaboration tools for themselves and their teams. They may have used Mattermost personally, or in a previous role, or heard about the product through word of mouth, review sites, or discovered Mattermost through web search.

They discover, download, and install Mattermost using a deployment guide. Over time, as the number of users grows beyond a single team, typically an IT administrator will be interested in the user management and access control features in Mattermost Professional, and be interested in getting a 30-day trial version license key to upgrade to Mattermost E0 and activate the trial key.

A subscription license to Mattermost Professional can be purchased online through our self-serve process, through a channel partner, or by contacting a member of the Mattermost sales team assigned to the territory.

As the deployment of Mattermost grows within an organization, typically past 250 or 500 users, the customer's procurement organization may be interested in advanced features and customization available in our Mattermost Enterprise offering.

Self-served motions

For Mattermost Professional, we have self-serve options to purchasing subscription licenses by credit card.

Sales-served motions

We're focused on a number of sales motions to turn leads and prospects into customers.

Champion-led inbound direct

Prospect comes to us to buy. In this motion, developers or a System Admin deploys the open source or cloud free version of Mattermost, adopts its usage, and realizes value for a small group (~20 for cloud and 5-25 for self-hosted). When they want to scale usage beyond 25 and need administrative features like user management, SAML SSO, and the champion contacts IT and procurement to purchase. IT or procurement contacts Mattermost and is directed to the sales team to discuss a purchase, ask for volume discounting, answer security, compliance or technical questions, and/or negotiate MSA terms on their way to a purchase.

In the meeting, Mattermost AE probes to get a detailed understanding of the customer’s situation and needs using a MEDPPICC framework, and works with the prospect’s IT, procurement, champion, economic buyer and other stakeholders to help the customer envision their success with Mattermost, complete an initial purchase, and set up the account for success in the post-purchase journey.

Key Input: This process often begins with a Marketing Qualified Lead ("MQL") of a certain type (pricing quotation or "Contact Us" request) indicating a "hand held high" level of interest in a purchase, and a work email which can be used to determine the organization from which the MQL originates and can be used to identify the correct member of the sales team to lead and execute on our process based on territory and industry assignments.

This process can also begin with a Product Qualified Lead ("PQL") which is a type of MQL (has work email and can be mapped to a sales person) that has an indication of product adoption and ideally trial activation. In-product trial requests are an example of PQLs that can be used as a starting point for sales to accelerate this motion.

Champion-led inbound channel

Similar to Champion-Led Inbound Direct journey except prospect buys through a channel partner rather than working with our sales team directly. In some cases we don’t have MEDPPICC information nor relationships with the key stakeholders at the accounts, and need to build up that context in order to properly connect with the account.

Key input: The inputs for this motion are the same as for "Champion-Led Inbound Direct" (above) with the exception that PQLs and MQLs may be shared by our sales team with a channel partner, who may have relationships (e.g. vendor agreement with a prospect) or capabilities (e.g. speaking languages that the Mattermost field doesn't) that we don't have.

Sales-led warm outbound

Identifying organizations where the free version of Mattermost is used, contacting people who didn’t reach out to us, and selling our way to close a new customer.

In this journey, the Mattermost sales team, either BDR or AE depending on region and segment, identifies an account where someone seems to be running the open source version of Mattermost (through webchat, contact requests, E0 download data, cloud trials, enterprise trials, noticing “Mattermost” skillsets in LinkedIn profiles, etc.), identifies potential contacts (using ZoomInfo, LeadIQ/LinkedIn Sales Navigator, Demandbase and other resources), and outbounds (via email, LinkedIn, and social media) to different personas in the target organization to eventually connect with Mattermost champions, and for the AE to share the vision, benefits, use cases, ROI, and case studies of our commercial offerings, along with technical pre-sales support, and guide the prospect into becoming a customer.

Key input: The minimum input is a Marketing Qualified Lead ("MQL") with a work email (so organization can be identified and the right sales person assigned), indications of early interest in Mattermost (e.g. newsletter sign-up, unactivated trial request, etc.), and product usage in some form (after MQL identifies the organization, sales can review public information like LinkedIn bios, blog posts, social shares from company employees, open source contributions, etc.).

In an outbound motion the intent is to reach multiple people in an organization, not just the person taking an MQL-creating action, so that marketing and sales resources can be applied to accelerating early interest into envision and unlocking value into purchase and expansion decisions.

Sales-led cold outbound

Selling into organizations that aren’t known to be using Mattermost but who are similar to existing Mattermost customers and could potentially benefit from our offerings, and potentially showed early interest.

This starts with BDRs and AEs focusing on a list of organizations - ”Named accounts” - that aren’t known to use Mattermost, but are similar to existing customers who benefit from Mattermost, finding and contacting the right people at the organization to share about the ROI and benefits of Mattermost solutions, getting meetings, and getting agreement to run a trial to prove that Mattermost would solve the issues the prospect is facing, running the trial with technical pre-sales support, and closing customers who can understand the vision for how Mattermost solves their urgent needs, with a proof of value in the trial to validate the purchase they are making.

Key input: Cold outbound can be started with just a list of "Named Accounts" that we believe would have similar needs and buying patterns as existing Mattermost customers. Ideally there are also MQLs similar to "Sales-Led Warm Outbound" though without the requirement of free usage to start this process.

Channel-led outbound

In some countries/regions, channel partners may execute Sales-Led outbound motions in partnership with our sales teams. This motion can be particularly additive in countries/regions and organizations with languages and culture that can’t yet be supported with our internal sales organization, or to reach the existing customer base of a channel partner who are likely to have similar needs to existing Mattermost customers and likely to buy (e.g. Carahsoft/FedResults).

Key input: The key input for a channel partner is training, enablement and on-going support on how to idenitify and call on high potential existing customers to consider, evaluate and purchase Mattermost offerings.

This motion is not yet broadly used, as the majority of channel activity is currently from "Champion-Led Inbound Channel" (described above).

Frequently asked questions

What keeps other companies from using your open source software to create offerings that compete with your paid products?

We use the acronym "TACTICAL" to summarize the approach to maintaining differentiation of the paid version of our offerings to offerings a competitor may create from our open source code base:

• Test infrastructure: We use SaaS QA which isn't included in the open source version.

• Alignment: Developer features are free. Paid features are for managers and IT pros, who are less likely to spend time and effort forking and maintaining an open source project vs. deploying budgets to purchase paid features.

• Core committers: We work with an active community of core committers to keep the project and business in sync.

• Threat intelligence: Mattermost's responsible disclosure policy means forks will lag in threat intelligence.

• Innovation: Regular ship cycles and high velocity innovation rapidly lower the value of forks.

• Compatibility: Only genuine versions upgrade smoothly to new releases and security patches.

• Architecture: Modular architecture makes the need to fork rare.

• Licensing: Mattermost's trademark is registered internationally, forking requires renaming.

Mindsets are “tool sets for the mind” that help us find blindspots and increase performance in specific situations. They’re a reflection of our shared learnings and culture in the Mattermost community and at Mattermost Inc.

To make the most out of mindsets, remember:

• Mindsets are tools: Use common sense to find the right mindset for your situation. Avoid using ones that don’t fit.

• Mindsets are temporary: Try on a mindset the way you’d try a tool. You can always put it down if it doesn’t work.

• Mindsets are not laws: Mindsets are situation-specific, not universal. Don’t use them to debate.

When you read about great leaders, they share mindsets relevant to success in their specific situations, which differ from their peers. Remember that “advice is personal experience generalized” so be mindful about what you apply.

In this context, here are mindsets for Mattermost:

Learn, Master, Teach

Learn a new topic quickly, develop mastery (be the smartest person at the team/company/community on the topic), then teach it to someone who will start the cycle over.

The best teachers can speed colleagues to surpass them. This mindset helps us constantly grow and rotate into new roles, while preventing single-points of failure where only one person is qualified for a certain task.

Slow is Smooth, Smooth is Fast

Rushing to get something done can create confusion, errors, and/or (paradoxically) delays.

When you feel rushed, consider slowing down and taking a moment to ask: What would it look like for this project to be running smoothly?

If you're running a collaborative project, consider:

1. Are the people I'm working with clear on the intent of this project or workflow?

2. Is everyone clear on who needs to do what?

3. Are we aligned on the measures that signal if our work is a success?

Getting to a "Yes" on these three questions can smooth out your process, and move things faster.

Boring Solutions

Use the simplest and most boring solution to solve problems.

The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology or methodology just to make your work more fun; using established and proven tech and processes that best match our needs to ensure a more stable and more familiar experience for you and other contributors.

When facing a high impact problem without a simple and obvious solution, focus your time on:

• Understanding the problem you're solving.

• Understanding how others have solved the same problem in an enduring way.

• What vital changes, if any, are needed to apply a proven solution that works.

More: Read GitLab's boring solutions mindset and Dan McKinley's blog post on choosing boring technology.

Emotion, Assumption, and Priority

Consider when rational people disagree, the cause often comes from one of three areas: emotion, assumption, and priority. Understanding the underlying difference in thinking can help us get to agreement faster:

1. Emotion: Is there a strong emotion biasing the discussion? Talking through that emotion can often solve an issue. It’s okay to have emotions. We're humans, not robots.

2. Assumption: People may have different underlying assumptions (including definitions). Try to understand each other’s assumptions and get to agreement or facts when you can.

3. Priorities: Finally, people can have different priorities. When everyone’s priorities are shared and understood it’s easier to find solutions that satisfy everyone’s criteria.

While the emotions, assumptions, priority mindset won’t work for everyone in every case, it’s helped resolve complex decisions in our company’s history.

Likes and Wishes

An easy way to check in with team members about how things are going.

• What do you like about how things are going?

• What do you wish we might change?

Use these one-on-one or in a group as a way to open conversations about what to keep and what to change in how we do things.

Drafts at 1%, 50%, 99%

Being clear on expectations when asking for someone’s review can help speed and smooth the process. In this mindset, there are three types of review:

• 1% Draft: Completely open to ideas and changes in direction. Rework is inexpensive.

• 50% Draft: Half complete work. There is structure, but also a lot of room for change. Some rework is inexpensive, some is expensive.

• 99% Draft: Nearly completed work. Rework at this point is very expensive.

Shoulder Check

When a new owner takes over a process or a project from a previous owner, there are a finite number of “blindspots” of which the original owner is aware and the new owner will need to understand.

Using the analogy of changing lanes while driving a vehicle and learning to do a “shoulder check” for information that is not visible from standard controls, we have a process for the new owner and previous owner to jointly review processes until the transfer is complete.

This process is similar to Mini-boss, End-boss, except that the mini-boss is also the new owner of a process, and not only a reviewer. Shoulder checks should be requested by new owners to avoid “crashing”:

• Making changes to systems that break existing processes may lose data and hurt the productivity of others downstream without notice and without a replacement system in place (behavior known as “Dead Tarzan”).

• Repeatedly investing in mis-prioritized projects due to a misunderstanding of requirements from project stakeholders and insufficient confirmation of intended outcomes.

Even when not crashing, as part of our Self Awareness leadership principle, top team members will constantly be seeking feedback and review from people around the company.

Brown M&Ms

A “brown M&M” is a mistake that could either signal dangerous oversights in the execution of a project, or be a completely innocuous and unimportant error. When a brown M&M is found, aim to rule out a dangerous error as quickly as possible. Do fast drilldowns and systematic checks to see if more brown M&Ms are found, and if so, an entire project may need to be reviewed.

Examples of brown M&Ms may include:

• Significant mistakes in process, consistency or documentation suggesting lack of review or lack of understanding of the pre-existing system.

• Ambiguous definitions that would make completion of a procedure difficult or unpredictable.

The name "brown M&M" comes from a safety technique used by the American music band Van Halen, who had to set up large, complex concert stages in third tier cities, where few local workers had experience with the safety standards vital to construction. In the contract rider with each venue, Van Halen required a bowl of M&M candies with all brown M&Ms removed. Failure to provide the bowl was grounds for Van Halen’s stage crew to inspect all of the local vendor’s work for safety issues, because it meant the vendor had not paid attention to detail, and safety could be at risk.

Correct Minimums: Medic, Field Surgeon, Plastic Surgeon

When making project investment decisions, we optimize for high impact in the context of customer obsession, empowered by ownership, while being constrained by “be proud of what you build”.

The failure case is over-investing in processes and infrastructure, stealing mana from higher priority work, reducing speed and agility for the company and unnecessarily increasing cost and bureaucracy.

The objective of optimization is to invest at minimal levels for efficiency and safety while maximizing impact.

In making these trade-offs, consider the following mindsets:

• Correct Minimum 1: Medic

  Safely fix something that is important, broken, and dangerous as fast as possible. Speed is critical - don't worry about “leaving a scar” on our architecture or business process, just own it and get it done. Solve the problem, do not overbuild.

  Example: Something incorrect on our public website with more than 100 page views a month should be fixed immediately and not delayed to be done with a longer-term project, such as a website redesign. If the staging server cannot be pushed, this means manually fixing production and duplicating that change on staging, rather than trying to fix staging.

• Correct Minimum 2: Field Surgeon

  Triage tasks that are important and broken but not dangerous, and fix the most important things with a minimum time and cost. Scarring should be a low-priority consideration – it's fine to leave scars and it's fine to spend a little energy to avoid big ones. Solve the problem for the next stage of growth, but don’t solve it in two to three stages ahead.

  Example: In Mattermost, spend 2 mana to enable automated messages over 4000 characters to be broken into multiple posts instead of being rejected, which is a problem every developer hits when they attempt to output log information via curl commands.

• Correct Minimum 3: Plastic Surgeon

  Fix and optimize critical, high volume flows in our customer experience and product with heavy investment if needed to make high impact changes. Scars can be avoided and removed to produce a high impact result.

  Example: Click-tracking traffic on about.mattermost.com and optimizing flows to direct visitors to learn about the product and downloading it is a flow that should be continually optimized.

Mini-boss, End-boss

After completing the initial draft of a project, there may often be more than one reviewer to approve changes. This may be for different disciplines to review the work (for example, both development and design teams reviewing code changes to the user experience) and it may also be for reviewers with different levels of experience to share feedback.

When reviewing significant user interface changes, code changes, responses to community or customers, or changes to systems or marketing material changes, it is ideal to have at least two reviewers:

• Mini-boss: Reviewer less experienced in domain or Mattermost standards for the first review.

• End-boss: Reviewer more experienced in domain or Mattermost standards for the final review for the discipline (e.g. development, design, documentation, etc.).

This system has several benefits:

1. The Mini-boss provides feedback on the most obvious issues, allowing the End-boss to focus on nuanced issues the Mini-boss didn’t find.

2. The Mini-boss learns from the End-boss feedback, understanding what was missed, and becoming a better reviewer.

3. Eventually the Mini-boss will be as skilled at reviewing as the End-boss, who will have nothing further to add after the Mini-boss review. At this point, the Mini-boss becomes an End-boss, ready to train a new Mini-boss.

The naming of this term comes from video games, where a person submitting material for review must pass a “mini-boss” challenge before a “end-boss” challenge for different disciplines.

Savor Surprises

When we make important decisions quickly it's important to run at least a lightweight analysis to identify blindspots that could put success at risk. "Savoring surprises" means discussing unexpected findings from an analysis and understanding root cause in order to de-risk our original plan and/or find new opportunities.

Example: In our early days, just months after launching our first commercial product Mattermost had a product roadmap for security and DevOps features that was vetted by customer roadmap reviews. We "savored the surprise" that custom emojis (which we assumed was a vanity feature to be cut) was highly important to support legacy processes that used them to communicate different outcomes of an automated process, like a build break. The surprise made our roadmap more valuable and effective.

A good analysis will result in surprises uncovering blindspots. An analysis that has no surprises is a surprise in itself and the blindspot should be determined. Did the analysis use the right data and methodology? Was it free from the unconscious or conscious bias of someone influential?

More: Watch Scott Cook's talk on savoring surprises.

RAPID for Complex Projects

When practical, projects and decision-making should be run at the lowest possible level of the organization, by people who are closest to the facts and data.

When a project is complex and involves many stakeholders, a different approach may be needed. We use a RAPID framework for complex, multi-stakeholder projects where clarity in the roles of stakeholders is vital.

RAPID is an acronym for the five different roles a stakeholder might be asked to take on in a complex project: Recommend, Agree, Perform, Input, Decide.

Each stakeholder can take on one or more roles:

More: RAPID framework from Bain Consulting.

Current Terms

The following lists current terms actively used at Mattermost. You can also see Tombstoned Terms for terms that have either been modified or deprecated. We use Tombstoned Terms to preserve links to previous definitions so clarity is maintained.

0/5, 1/5, 2/5, 3/5, 4/5, 5/5

We use “x/5” to concisely communicate conviction. 0/5 means you don’t have a strong opinion, you are just sharing an idea or asking a question. 5/5 means you are highly confident and would stake your reputation on the opinion you’re expressing.

Example: "0/5, I think before archiving a channel a user should type in the name of the channel to make sure they really want to do it" expresses low conviction and indifference in the suggestion. The decision maker should feel free to ignore the input. As another example: "4/5, I think before archiving a channel a user should type in the name of the channel to make sure they really want to do it" expresses high conviction and the decision maker may want to ask more questions to understand whether emotion, assumption, or priority is behind the feedback.

Best Practices

We try not to use the term "best practice" at Mattermost, as it's counter-cultural to our focus on iteration, self-awareness, and earn trust. Iteration means there is always opportunity to grow and improve and so we never reach our "best".

AA

Refers to both an As Appropriate interview as well as the As Appropriate interviewer. Final interview required before making a decision on a new hire.

AOR

Area Of Responsibility defines the area for which a DRI is accountable. The AOR page provides information on AORs across the company.

ARR

Annual Recurring Revenue (“ARR”) is a measurement for time-limited subscription contracts. ARR normalizes contracted recurring revenue into a one year period to allow for like-kind comparisons between contracts that have differing start/end dates and/or different contract lengths. In a recurring revenue model, ARR represents the anticipated total revenue from all active contracts for the future 12 months from any measurement period. “Active” is defined as starting from customer contract signing date, not subscription start date. ARR does not include revenue from non-recurring items such as one-time setup fees or professional services.

For example, total ARR from 3 separate customers would be as follows:

Customer A: 6-month contract totaling $60,000. ARR = $120,000 ($60,000/6 * 12) Customer B: 12-month contract totaling $240,000. ARR = $240,000 Customer C: 15-month contract totaling $45,000. ARR = $36,000 ($45,000/15 * 12) Total ARR for Company = $396,000 ($120,000 + $240,000 + $36,000)

Bookings

The ARR associated with sales transactions closed during the period. Note that Bookings and Billings are different, particularly for pro-rated contracts and multi-year contracts. Billings corresponds to the amount the customer is invoiced.

For example, Customer A signs a 3 year paid upfront transaction for $300,000. For Customer A, the bookings amount would be $100,000 ($300,000/3 years = ARR of $100,000) and the billings amount would be $300,000 (what we actually invoiced the customer at time of order signing). Customer B has a contract for 100 licenses at $50/year/license for 12 months, for total ARR of $5,000. They decide to add 25 more licenses after 4 months. For Customer B, the bookings amount would be $1,250 (25 * $50/year) and the billings amount would be $833.33 (25 * $50/year * 8 remaining months/12 months total contract).

Bug

An obvious error in Mattermost software that is typically a code defect. Changes required to accommodate unsupported third-party software (such as browsers or operating systems) are not considered bugs - they are considered improvements.

CAO

Contract Accountability Owner is a DRI for ensuring a contract meets our guidelines and standards ahead of final approval by a company signatory. Also see listing of CAOs.

Churn

When an existing customer completely cancels and is no longer a continuing customer. Dollar value of ARR is $0 after the reduction.

COM

COM is short for Customer Obsession Meeting, which is our “All Hands” meeting focused on how we’re aligning the company to serve our customers.

Contraction

When an existing customer decreases the dollar value of their ARR, either by decreasing the number of licenses, decreasing the number of products and/or the discounting being applied is increased. Note that the decrease is classified as “contraction” if there is still some amount of ARR remaining after the reduction.

Country/Region

Because the term "country" may be either controversial or incorrect when describing a geographic area governed by a state-like political entity we use the term "country/region" to avoid any accidental or implied judgement on the independence of a region. If the term "country" appears to be incorrectly used, when "country/region" is more appropriate, please contact info@mattermost.com.

Collapsed Reply Threads (CRT)

Collapsed Reply Threads (CRT) is a Mattermost Messaging feature available in beta offering an enhanced experience for users communicating in threads and replying to messages. When enabled, Collapsed Reply Threads improve users’ ability to process channel content, find, follow, and resume conversations more easily, and keep threaded conversations focused. See our Organizing Conversations using Collapsed Reply Threads (Beta) product documentation for details.

Core Committers

Core committers are staff or community developers with the responsibility to contribute and review Mattermost source code.

CSM

Customer Success Management function at Mattermost responsible for retaining customer revenue, with quarterly & annual targets, including customer relationship management, executive relationships, and quarterly business reviews.

Customer

The primary external audience we are focused on for an initiative, which could be an end user without budget (if our goal is adoption and engagement) or a buyer (if our objective for the initiative is revenue). A customer does not include internal staff, since staff are not external.

Dark Actions

The act of using non-web-discoverable formats (Mattermost channels requiring login, Google docs that aren't web searchable, Zoom call, email, etc.) to share non-confidential information or processes.

Example: Giving someone instructions on how to set up Okta for MFA on the community server in a DM rather than writing it into a handbook entry for all new staff to use and re-use.

Dark actions create false openness. Open actions are highly preferred.

DE

Deployment Engineering function at Mattermost responsible for accelerating seats deployed at $50K+ accounts, focusing on single customer pain points & needs by working directly with customers in partnership with post-sales and revenue retention teams, and providing expertise on how to run and deploy Mattermost and the platform as a whole.

Dead Tarzan

Discarding an imperfect solution without a clearly thought out and working alternative. Based on idea of Tarzan of the Jungle letting go of a vine without having a new vine to swing to.

Decking

A term for shipping something that is far below quality standards. This term is used by mountain climbers to describe falling off the side of a mountain, which often involves a series of failures, not just one.

Dev Mana

A specific type of mana for developers similar to “points” or “jelly beans” in an Agile/Scrum methodology. On average, full time Mattermost developers each complete tickets adding up to approximately 28 mana per week. A “small” item is 2 mana, a “medium” is 4, a “large” is 8, and any project bigger needs to be broken down into smaller tickets.

DRI

Directly Responsible Individual means a human individual who is accountable for a given Area Of Responsibility. A DRI is a single person, not a group of people. If there is a shift schedule, define each shift as a separate AOR (e.g. Tier 2 Mobile Support Escalations Weekdays 8am to 5pm Palo Alto time). If you are unsure who is the DRI, make the AOR more specific until the DRI is clear.

Edge

“Edge Release”, a version of Mattermost which indicates the latest unstable release off of the main branch.

ESR

“Extended Support Release”, a version of Mattermost maintained for a longer period of time that will receive security fixes.

Expansion

When an existing customer increases the dollar value of their ARR, either by adding licenses, adding additional products and/or reducing the discount being applied.

Expert Mode

Expert Mode (also known as "Crimson Force Field") is when documentation or on-screen text is written for someone with considerable knowledge or expertise, instead of being designed for a new learner. In general, try to state things simply rather than speaking to just the “experts” reading the text.

If something is extremely difficult to understand, and yet still justified in the mind of the writer, we call it “Crimson Force Field”. This term is intended to evoke the emotional response of coming across something that is difficult to understand, so writers of Crimson Force Field material can empathize with the readers. Crimson Force Field is drawn from an esoteric episode of Star Trek and it is unlikely anyone but the originator of the term understands its complete meaning. Crimson Force Field is itself Crimson Force Field.

False Openness

Keeping non-sensitive information that would be helpful for staff and community to know out of public web search through the use of dark actions. Often false openness is unintentional, though after staff members are educated on the topic and empowered to use open actions, continued use of dark actions would appear to be deliberate.

FF

Fast Futures function at Mattermost responsible for prototyping and validating enterprise customer needs ahead of product engineering investment, which was the approach applied to Calls, MS Teams and OpenOps prior to adding the functionality to the mainstream roadmap.

GNN

A status update format that is split into three categories: Going Well, Not Going Well, Next Actions. Read more about GNNs here.

Gross Margin (“GM”)-Weighted Magic Number

A measurement to determine sales efficiency. The GM-Weighted Magic Number is determined by taking the Net Change in ARR for the Period (or New Logo & Expansion ARR in the period less Churn & Contraction) times the Gross Margin percentage, divided by total Sales & Marketing spend in the prior period. This metric attempts to quantify how much Sales & Marketing spend is required to generate ARR.

Gross Margin & Gross Margin %

Gross Margin is determined by taking Revenue less Cost of Goods Sold (“COGS” or “COS”). COGS or COS are the direct costs associated with delivering the product or service to existing customers (e.g. cost of Success, Support, hosting costs, etc.). Gross Margin % is calculated by taking Gross Margin and dividing by Revenue.

Gross Revenue Retention

A measurement that attempts to quantify how well a company retains its existing customers. Gross Revenue Retention (“GRR”) is calculated by taking Beginning Balance ARR less Churn/Contraction and dividing by Beginning Balance ARR. Because both New Logo ARR and Expansion ARR are excluded from this calculation, this value cannot exceed 100%.

HW - Help Wanted

Help Wanted tickets, which are vetted changes to the source code open for community contributions.

Improvement

A beneficial change to code that is not fixing a bug.

Iteration

Iteration means being able to quickly improve on something by shipping a minimally viable change in how we do things. It's the opposite of the "wait, wait, wait, ship" method we call the Windows Vista Approach.

Latest

“Latest Release”, a version of Mattermost which indicates the latest stable release.

LHS

The “Left-Hand Sidebar” in the Mattermost team site, used for navigation.

Majority Regions

Countries and regions outside the United States are referred to as "majority regions". We use this term for a few reasons, a) we use the word "majority" to remind everyone that the ~300M United States are only a tiny fraction (<5%) of the world's 7 billion people (many American companies refer to the U.S. as "domestic" and the rest of the world as "international" which is counter to the inclusive culture at Mattermost), b) we use "regions" instead of "countries" because there are political issues with some locations.

For example, we should always refer to Taiwan as a "region" and not a "country" due to geo-political issues.

Mana

An estimate of total energy, attention and effort required for a task - not a measure of amount of code to be changed or cumulative time needed for a change.

A one-line change to code can cost more mana than a 100-line change due to risk and the need for documentation, testing, support, and all the other activities needed.

Every code change added has an initial and on-going mana cost in technical debt, test case coverages, and supportability, which is taken into account in feature decisions.

MBR

The “Monthly Business Review”, where senior leadership team and department heads work with functional leaders to clear escalations, make key decisions & have concrete next steps for the next review period.

MLT

The “Mattermost Leadership Team”, senior leadership team and department heads working with the CEO in MLT meetings and offsites.

MME

A customer that is any Midmarket ("MM") or Enterprise ("E") organization, including public sector, with 2,500 employees or more, buying a Mattermost subscription that's not on a non-profit or educational discount.

MOR

Monthly Operating Review. A monthly review of operations from each department including a GNN and metrics.

MQL

A Marketing Qualified Lead refers to a prospect deemed to have a higher likelihood of becoming a paying customer based on their marketing activities, e.g. certain website activities (content downloads, etc), trial activations, demo or quote requests, and more.

Net Dollar Retention

A measurement that attempts to quantify the ability to both retain and grow our existing customers. Net Dollar Retention (“NDR” or Net Revenue Retention “NRR”) is calculated by taking Beginning Balance ARR + Expansion ARR - Churn/Contraction and dividing by Beginning Balance ARR. Because NDR includes the impact of Expansion ARR, this value can exceed 100%. NDR does not include the impact of New Logo ARR. This measurement is typically favored by investors.

Both GRR and NDR are typically presented on an annual basis, using a static Beginning Balance at the beginning of the year. For annual presentation, this number represents total Churn/Contraction for the year divided by the beginning balance of ARR at the start of the year. For mid-year discussion and presentation, this number represents total Churn/Contraction for the period (e.g. first half) divided by the beginning balance of ARR at the start of the year. It is important to note that annual churn will naturally present lower than mid-year churn, using this method, due to the fact that the numerator is changing but the denominator is not.

Nerfs and Buffs

Nerfs and buffs are the framework for setting culture at Mattermost.

A "nerf" is a downgraded experience as the result of a behavior.

For example, if half of a team is traveling to a conference and holds a team meeting in a hotel room and the other half calls in remotely but they can't see everyone in the room and audio is low quality, then the team is "nerfing" their remote colleagues. The people in the hotel room are downgrading the experience of their remote colleagues.

Under this framework, we want to discourage behavior that nerfs remote work, so if your team is holding in-person meeting with remote colleagues, please split up to take the call from separate areas so everyone can be seen and heard.

A "buff" is an upgrade experience as the result of a behavior. If a remote team is meeting on a topic with a clear, concise written proposal requesting asynchronous feedback, people who share high-quality feedback asynchronously ahead of the meeting may have an out-sized influence on iterations of the document ahead of the meeting, compared to people who don't provide asynchronous feedback ahead of the meeting.

Here we want to buff asynchronous communication by focusing review on asynchronous comments ahead of live comments.

Culture is the set of behaviors that are nerfed and buffed. As a remote-first culture, we want to buff behavior that promotes asynchronous communication and remote work. We want to nerf behavior that creates unnecessary synchronous meetings.

New Logo Sale

A standard sale with a customer that has never previously purchased any kind of product or service from Mattermost, either directly or indirectly through a purchase by an affiliate on the customer’s behalf. A sale shall be deemed to be a New Logo Sale even if one of customer's affiliates is already a customer of Mattermost so long as (a) the entity making the purchase has never itself previously made a purchase or has had a purchase made on its behalf, and (b) the new sale is either a purchase of a license key to a new Self-Hosted server independent from other Mattermost installs or a purchase of a subscription to a new Cloud workspace independent from other Mattermost workspaces.

Open Actions

Term for publicly documenting information in a web-discoverable format (GitHub Issue, Staff Handbook entry, forum post, etc.) prior to sharing guidance to staff and community members. We prefer open actions to dark actions.

PE

Product Engineering function at Mattermost responsible for the software architecture, design and development of the product focused on delivering high quality, reliably built and maintained features, systems and improvements applicable to the broad range of ideal customers.

PgM

Program Management function at Mattermost responsible for leading and executing key cross-functional programs, working with cross-departmental stakeholders to increase operational efficiency and accelerate alignment towards customer and company objectives.

PO

Product Operations function at Mattermost responsible for infrastructure engineering and customer reliability engineering.

PTO

Paid Time Off is time away from work paid for by the company to staff, including holidays, vacations, and approved leaves of absence. See PTO.

Renewal Success Rate

A comparison of the actual dollar value renewed compared to the total dollar value of contracts up for renewal in the period. This measurement attempts to quantify the “success rate” of renewals scheduled in the period, and cannot exceed 100%. Unlike GRR or NDR, this measurement excludes the impact of any multi-year contracts that are not up for renewal in the period.

RHS

The “Right-Hand Sidebar” in the Mattermost team site, used for navigation.

SAL

A Sales Accepted Lead refers to a prospect that a Sales team has spoken to either in-person (e.g. tradeshow, conference, dinner), or remotely (phone call, video call), and validated the prospect has a legitimate potential to convert to a paying customer.

SBIR

A Small Business Innovation Research (or SBIR) program funded by the U.S. government to accelerate technology innovation in partnership with small businesses. Funding takes the form of contracts or grants. The recipient projects must have the potential for commercialization and must meet specific U.S. government R&D needs.

The program includes Phase 1 SBIRs (concepts with no development work), Phase 2 SBIRs (development work to create a prototype with a potential for commercialization), as well as larger contracts via TACFI, STRATFI and more: https://afwerx.com/divisions/afventures/stratfi-tacfi/

Spinmint

Spinmint refers to our first generation of automated infrastructure to spin up test servers to evaluate pull requests. The word "spin" comes from the original name of our company, "Spinpunch, Inc." (before we became ("Mattermost, Inc.") and the word "mint" as a short, unambiguous, easy-to-spell name referring to a factory method pattern.

SpinWick

New test servers that use the cloud infrastructure and can be spun up on pull requests to test changes. The name is reference to first generation infrastructure, spinmint, combined with an arbitrary reference to a movie that some people saw called “John Wick”.

SOM

Standard Operating Metrics are metrics tracked monthly by each department as indicators for operating health and status.

TAM

Technical Account Management function at Mattermost responsible for retaining & expanding customer revenue, including technical adoption & bottlenecks, technical onboarding, issue coordination and escalation.

Tombstoned

Replacing a webpage with a link to the new page created so that people using the original link can easily find the new page. An example of tombstoned terms can be found at the bottom of this page.

YouTweetInFace

A reference to the major social media platforms: YouTube (“You”), Twitter (“Tweet”), LinkedIn (“In”), and Facebook (“Face”). The YouTweetInFace channel is used to discuss social media posts before asking contributors and community to engage with the content. The name is a reminder that our tone and approach to social media needs to be thoughtful, memorable, and ideally bring a smile.

Windows Vista Approach

Instead of working iteratively a "Windows Vista approach" attempts to ship significant changes in a complex one-time effort, which seems like a good idea at the time but ends up causing delays, wasted effort, and numerous avoidable errors.

This tempting, high risk approach is named after Microsoft’s “Windows Vista” operating system, one of its most famous examples.

Mattermost Cloud

Describes cloud infrastructure within AWS, where the Cloud Provisioning server, Mattermost Operator, databases, file storage, etc exist.

Installation

An installation is an instance of Mattermost, otherwise known as a Mattermost Workspace. Internally, the term Installation generally implies it is hosted inside Mattermost Cloud.

Workspace

A workspace is an instance of Mattermost, otherwise known as an Installation. While it can be used interchangeably with "Installation", "Workspace" generally implies it is a self-hosted deployment.

Cloud Server

An ambiguous term that describes an Installation (ie, Mattermost Workspace) which is hosted in Mattermost Cloud.

Cloud installation

An Installation, hosted in Mattermost Cloud, with the necessary configurations to represent a Mattermost Cloud SaaS workspace (ie, configs, license, connections to CWS, configurability restrictions, etc) like one created from https://customers.mattermost.com

Self-Hosted Installation

An installation, hosted in Mattermost Cloud, with the necessary configurations present to represent a self-hosted workspace (ie, configs, license, configurability, etc).

Tombstoned Terms

The following is a list of terms no longer used with links to their definitions or notes on their deprecation. Tombstoned Terms use H3 headings on this page to distinguish them from active terms, which are H2 in heading formatting.

Tomb-stoned

Previously hyphenated, now not hyphenated, see Tombstoned.

Vacation-ready

A team and process that is ready for a key member to go on vacation, or spend time away from work.

Mattermost Leadership Team (MLT)

This section outlines:

• Introduction to MLT

• The operations of administrative, tactical, and strategic meetings

• Process for alignment and cascading communications

• Process for quarterly business reviews, planning, and board meetings

Introduction to MLT

• Ian Tien: Co-Founder and CEO

• Corey Hulen: Co-Founder and CTO

• Kendra Niedziejko: CFO

• David Reardon: Chief Revenue Officer

• Nirosha Ruwan: VP, Legal

• Chen-i Lim: VP, Product

• Natalie Jew: VP Human Resources

Fiscal Year Planning (1%)

Preparation for the annual plan and budget for the next fiscal year begins in the second half of the current fiscal year.

Q3 Planning for Next Fiscal Year

In Q3 we have three goals:

1. Fiscal year defining objectives for company and departments based on our latest thinking.

2. Product Strategy and direction for next fiscal year.

3. D0 & D1 Goals by MLT and MLX Directly Responsible Individual

Typically there is not pressure for budget or headcount discussions in Q3, focus is strategy.

Q3 Punchlist for Next Fiscal Year Planning

1. The company 3-year aspirations are reviewed

2. 1% Next Fiscal Year Strategy and Plan are drafted

3. At Q3 Planning Offsite, MLT reviews Strategy and Plan for next fiscal year developed from 1% draft

4. Action items are documented and developed around obstacles to success of next fiscal year

5. Draft budget based on Strategy and Plan and financial investments required to bring plan to life

Q4 Planning for Next Fiscal Year

The focus of Q4 is arriving at a 99% draft of the plan for next fiscal with alignment across MLT and departments, with obstacles mitigated, and headcount and budgets reviewed.

1. MLT and middle managers work through key defining objectives and map out D0 and D1 goals for next fiscal year

2. Finance works with MLT to draft financials plan for next fiscal year

3. Department heads work with their teams, peer stakeholders, and CEO to develop department D2 and D3 goals.

4. 99% department D2 & D3 goals are reviewed by MLT peers and CEO and agreed

5. Plan for next fiscal year

At Mattermost, we are using our mobile devices daily at work. This how-to document provides guidance on what steps you need to take when planning to migrate to a new phone.

GSuite two-factor authentication

For GSuite two-factor authentication, please follow these steps:

2. Select 2-Step Verification.

3. You'll be prompted to log in again to prove your identity.

4. Select Change Phone and follow the provided steps.

5. (Optional) If you’ve changed your phone number, update the phone number in the Google Security Center as well.

Okta two-factor authentication

For Okta two-factor authentication, please follow these steps:

2. Log in with your Okta credentials and authentication code from your old mobile device. If you can't sign in, please reach out to the IT team.

3. Select your name in the top right and select Settings.

4. If the Edit Profile button appears, enter your password if prompted.

5. In the Security Methods section, depending on the two-factor method you're using, it will show you Remove or Set up another.

6. Please choose Remove to remove your old device and Set up another to add your new device and follow the instructions on the screen.

For detailed steps-by-step instruction, please go to the links below:

• Andriod user : https://help.okta.com/eu/en-us/Content/Topics/end-user/ov-reset-register.htm

• iOS user : https://help.okta.com/eu/en-us/Content/Topics/end-user/ov-ios-reset-register.htm

The security team will assist you in removing access from your lost mobile device to your Mattermost resources, and walk you through the set up of a new mobile device.

Company Key Info

How Mattermost uses Mattermost

Channels

Think of Channels like rooms in a building. Public channels are open rooms that people can enter and leave freely. Private channels are like private rooms that are invitation-only. Direct Messages are like popping your head into someone's private office to have a conversation. Group Direct Messages are like popping your head in to a shared office to have a discussion.

All channels can be used to communicated, some are better at specific use cases than others:

Public channels

Find public channels from + > Browse Channels and join and leave based on your topics of interest. Use public channels for "open door" discussions of information relevant to everyone in the channel, for example News and Buzz is a channel to share updates on Mattermost being mentioned on social media and in press.

Private channels

Use private channels to collaborate on work that would benefit from privacy, and not appropriate for an "open door" discussion. For example, planning manager training, organizing our next MatterCon conference, procurement processes where financial data could be shared, launch planning activities (which can be fast changing and confusing if shared ahead of launch).

Direct messages

Use direct messages (or "DMs") to send quick notes to someone to get their attention, like "Running late" or "Can you comment on this ticket? [Link]". Avoid using DMs for collaborative work, as it's difficult to share context from a DM discussion with others--use Boards or group channels instead.

Group direct messages

Use group direct messages (or "GDMs") very sparingly, and ideally to send only ephemeral notes to a group like "Running late" or "Please get your forecasts in by end-of-day. [Link]". Once a GDM is sent, it can be difficult for some users to find the channel again, so it's best if it's not a store of data.

Boards

Think of Boards like a project board on a giant wall, with "Tickets" that can contain all sorts of rich information. You can use Boards to managing any project--goals, tasks, interview candidates, SWAG projects--and organize things based on custom properties, like categories, status, dates, numbers and people. Here's some examples:

Playbooks

Think of "Playbooks" as a set of binder on a shelf with plans and procedures for different incidents and processes. Based on the type of incident or process, the context (e.g. time of day) Playbooks will include steps to follow, people to notify and automation to kick-off to rapidly flow through, resolve, and learn from different "Runs" of a Playbook. Examples include:

Email

Think of email like a physical piece of mail you'd want to send to individuals and groups, who might forward the message to others, or reply to the original group. Examples include:

• Cascading Content - If you're making an announcement across management layers and you want to give each layer and opportunity to add context to the message or choose the people to whom it's forwarded and decide on timing, then email is the best choice. For example, if you're announcing a "company day off" you want to give different managers an opportunity to customize the message as it flows through to their teams, some managers who have on-call staff might have to make accomodations (on-call people need to work, but they can choose a different day off) while another manager who's team has been working on a massive project might want to give an extra day off for their teams, etc.

• Approvals - Written approvals that need to be circulated and archived are an excellent fit for email. Offer letter approvals are a good example, which need to flow through different HR and manager approval chains and ultimately archived in our HR systems.

• One new topic - If you have a new topic to discuss in a small group and there's not a good public or private channel, email is an ideal way to start. Choose email over DMs and GDMs if it's an on-going conversation - but choose DMs and GDMs for urgent and ephemeral topics, e.g., "Can you approve this thing?" / "The meeting invite link is broken!", etc.

Documentation

Documentation is like the policy manual for a company. As much as possible, document things publicly.

• Product Documentation - docs.mattermost.com - Make product documentation as public as possible.

• Operating Documentation - handbook.mattermost.com - Document our internal processes and operations.

• Mattermost.com - mattermost.com - Document our customer-facing information.

Contact us requests

All contact us

• Number of contact us requests via https://mattermost.com/contact-us.

Enterprise contact usrequests

• Number of contact us requests via https://mattermost.com/contact-us from Named Accounts or Enterprises with 5,000+ employees, in America, EMEA, Australia, or Japan.

Contributors

GitHub contributors

• Members of the open source community with contributions to Mattermost GitHub repositories.

  • This does not include internal Mattermost staff

• Definitions:

  • First Time Contributors: The first month someone contributes, they are considered a First Time Contributor that whole month.

  • Old Contributors: Anyone that is not a First Time Contributor.

  • First Contribution: The first contribution ever made by someone. Any following contributions will not be considered a First Contribution.

  • Examples:

    • Person A

      • 2019-01-02 Contribution 1

      • 2019-01-04 Contribution 2

      • 2019-01-05 Contribution 3

    • Would count as

      • 1 First Time Contributor + 1 First Time contribution + 2 Non First Contributions.

CS Account Health Score

Customer Success Account Health Score represents the overall health of a Mattermost SFDC Account.

• Account Has Open Opportunity w/ Renewal Risk Status = 'At Risk'

  • Account Health Score = 20%

• Account Has Open Opportunity w/ Renewal Risk Status = 'Early Warning'

  • Account Health Score = 50%

• **Note: If account has open opportunity w/renewal risk status of At Risk or Early Warning, it will override all other Healthscore metrics.

• Account has a completed Customer Reference

  • Customer Reference Score = 10 additional bonus points

• Account Has No Open Opportunity w/ Renewal Risk Status = 'At Risk or 'Early Warning'

  • Account Health Score = Tenure Score + License End Score + Ticket Score + Task Score

    • Tenure Score = 25 * Tenure Health %

      • Tenure Health %:

        • Tenure <= 0.5 Years: 10%

        • Tenure Between 0.5-1 Years: 50%

        • Tenure Between 1-2 Years: 75%

        • Tenure > 2 Years: 100%

    • License End Score = 25 * License End Health %

      • License End Health %:

        • License End <= 15 Days From Now: 10%

        • License End Between 16-30 Days From Now: 25%

        • License End Between 31-60 Days From Now: 75%

        • License End Between 61-90 Days From Now: 90%

        • License End > 90 Days From Now: 100%

    • Ticket Score = 25 * Ticket Health %

      • Ticket Health %:

        • Count of Tickets Past 90 Days >= 5: 25%

        • Count of Tickets Past 90 Days = 0: 50%

        • Count of Tickets Past 90 Days Between 3-4: 75%

        • Count of Tickets Past 90 Days Between 1-2: 100%

    • Task Score = 25 * Task Health %

      • Task Health %:

        • Days Since Most Recent Task >= 90: 25%

        • Days Since Most Recent Task Between 60-90: 50%

        • Days Since Most Recent Task Between 30-60: 75%

        • Days Since Most Recent Task <= 30: 100%

Downloads

Monthly Server Downloads

All Server Downloads

• Number of successfully completed unique TE (Team Edition) + EE (Enterprise Edition) downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget/curl downloads.

  Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.

Monthly Enterprise Account Server Downloads

• Number of Monthly Server Downloads among companies and organizations with over 5,000 employees.

New Monthly Server Downloads from Named Enterprise Accounts

• The first contact or lead from a Named Enterprise Account who is attached to an Account either manually by an AE or by Marketo, and who provides a business email on mattermost.com/download after downloading the Mattermost server binary.

  • Excludes Salesforce account types equal to Customer or Partner.

Monthly App Downloads

All Desktop App Downloads

• Number of successfully completed desktop application downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget / curl downloads.

  Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.

Finance

Financial numbers cater to a wide range of teams. Below you will find information on ACV, TCV, and ARR. ACV, TCV, Bookings are relevant to Sales/CS and ARR relevant to Finance/CS.

TCV (Total Contract Value)

What the customer bought

• TCV measures revenue from across the entire contract a customer signs.

• Recognized only in the Closed Won Month.

• TCV = Total Contract Value

ACV (Annual Contract Value)

What the customer bought annualized for the first year of their contract

• Recognized only in the Closed Won Month.

• ACV = (Total Contract Value / (End Date - Start Date)) * 365

Bookings

Standard financial term used to define how much sales credit is recognized for a deal. This is also the basis for all commission plans starting in FY21.

• If term length >= 1 year, Bookings = ACV

• If term length < 1 year, Bookings = TCV

• Net New and Expansion only

• Why would we have deals < 1 year?

  • True-ups

    • Customer owes MM 30K for Q1FY21

    • Booking would be 30K on the first day of Q2 (May 1)

  • Co-Term Renewals

  • Ramped Deals

    • Customer signs a 3 year deal on Feb 28, 2020. Year 1 = 50K, Year 2 = 100K, Year 3 = 150K

    • Bookings

      • 2/28/20: 50K

      • 2/28/21: 100K - 50K = 50K

      • 2/28/22: 150K - 100K = 50K

ARR (Annual Recurring Revenue)

What the customer bought normalized for one year length and reoccurs for length of contract.

• ARR is the value of the contracted recurring revenue of your term subscriptions normalized to a one-year period.

• Recognized from start to end of contract.

• ARR = (Total Contract Value / (End Date - Start Date)) * 365

• ARR increases and decreases based on the following categories of change:

  • New: Increase in ARR from $0 to > $0 & New Logo never seen before

    • Caused by a brand new and never before seen Account signing a contract

  • Expansion: Increase in ARR by an Account

    • Caused by seat increase, price increase, or product upgrade

  • Resurrection: Increase in ARR from $0 to > $0 & by a known Account

    • Caused by an Account churning and returning to Mattermost

  • Contraction: Decrease in ARR by an Account

    • Caused by seat decrease, price decrease, or product downgrade

  • Churn: Decrease in ARR from > $0 to $0 by an Account

    • Caused by an Account moving completely off of Mattermost

TCV vs. ACV vs. ARR

Example:

• Opportunity: Example Opportunity

• Close Date: 2019-05-07

• Amount = $250

• Start Date: 2019-06-15

• End Date: 2022-06-14

• Metrics Breakdown (see graph below):

  • ACV one-time $83 in May 2019

  • TCV one-time $250 in May 2019

  • ARR $83 from June 2019 until June 2022

Google Analytics

All Google Analytics data in Snowflake is at a daily level. See limitations.

Organic Traffic

• Organic Web Traffic is the daily unique visitors to *.mattermost.org, *.mattermost.com who originate from non-paid sources.

• Organic Search Traffic is the daily unique visitors to *.mattermost.org, *.mattermost.com who originate from an organic Google search.

Unique Pageview (UPV)

A Unique Pageview (UPV) aggregates pageviews that are generated by the same user during the same session. The metric combines the pageviews that are from the same person (a user in Google Analytics), on the same page, in the same session, and counts them as one.

• Unique Page Views (UPV) are calculated as the daily count of distinct pageviews per user per session to view a Mattermost web property webpage (list of web properties defined in Google Analytics Accounts).

Session

A session is a group of user interactions within a website that take place within a given time frame. A single session can contain multiple page views, events, social interactions, and ecommerce transactions. A single user can open multiple sessions. Those sessions can occur on the same day, or over several days, weeks, or months.

Session Expiration

As soon as one session ends, there is then an opportunity to start a new session. There are two methods by which a session ends:

• Time-based expiration:

  • After 30 minutes of inactivity.

  • At midnight.

• Campaign change:

  • If a user arrives via one campaign, leaves, and then comes back via a different campaign.

Google Analytics Accounts

1. mattermost.com

2. https://mattermost.com/ (old mattermost.com)

3. mattermost.org

4. developers.mattermost.com

5. integrations.mattermost.com

6. docs.mattermost.com

7. handbook.mattermost.com

8. licensing.mattermost.com

9. mattermost.gitbook.io/jira-plugin

10. pre-release.mattermost.com (which is old community.mattermost.com)

11. mattermost.zendesk.com

Google Analytics Limitations

• Stitch is used to pull Google Analytics data into Snowflake.

  • Stitch is only able to pull data at a daily level.

  • Aggregating up daily level to a monthly level causes double counting of users that may have visited the site more than one time in a given month.

Hiring

• WIP

Net Promoter Score (NPS)

NPS Survey

Mattermost NPS data is collected using an in-product survey on servers where the User Satisfaction Survey plugin is enabled. Users answer the question "How likely are you to recommend Mattermost?" by selecting a 0-10 score and can provide additional written feedback about their experience. Selecting a score and providing feedback are optional.

Net Promoter Score is computed as (% Promoters - % Detractors) and ranges from -100 (every user is a Detractor) to +100 (every user is a Promoter).

• Promoters (score 9-10): Loyal enthusiasts who will keep buying and refer others.

• Passives (score 7-8): Satisfied but unenthusiastic users who are vulnerable.

• Detractors (score 0-6): Unhappy users who can damage your brand.

If users edit their response to the survey on any particular server version, only the latest rating on each server version is used for computing NPS. Test server data is also removed via the excludable servers list and by trimming any responses submitted on a server version that has not been publically available for 21 days (time delay before an NPS survey is triggered after a server upgrade).

Based on the above calculation method, we can apply a time window (Quarterly Trailing NPS) and a version filter (NPS by Server Version) to represent and track the state of Mattermost NPS.

Quarterly Trailing NPS

Quarterly Trailing NPS represents the NPS score computed based on survey submissions received in the last 90 days. We target a 90 day window of NPS responses because it:

1. Encompasses responses across all server versions that are currently in use by customers (with surveys enabled), meaning it is representative of the state of user experience that customers are facing today.

2. Ensures we have a statistically significant sample size representing the server versions currently in use.

3. Helps us capture week-to-week variations in NPS while being less volatile than NPS by server version given the larger sample size.

NPS by Server Version

NPS by Server Version represents the NPS score computed based on survey submissions on a specific server version. While Quarterly Trailing NPS provides a representation of the state of user experience that our customers are facing, NPS by Server Version provides a representation of the user experience offered by the product in particular releases. As such, it's used heavily by the PM team to track the success of particular product team initiatives as they ship.

NPS by Server Version is a lagging metric since we need to collect a statistically significant sample size before reporting NPS for a server version. Based on historical data, ~2000 unique user responses (~1.5-2 months post-ship) are required for the NPS of a particular server version to stabilize.

NPS by Server Version can be volatile since it can be affected by the upgrade cadence of heavy usage servers. We typically see a surge in responses when surveys are triggered (21 days after server upgrade) for servers with large DAU, which can impact the NPS trend for that server version. Quarterly trailing NPS is not as affected by this since the sample size is larger and responses are submitted on various server versions.

Written Response Feedback

Users can optionally submit written responses to the NPS survey. These responses are reviewed and categorized by the PM team to allow us to stack rank certain initiatives for roadmap planning based on their impact to NPS, reach and effort to design, implement and test.

To determine impact to NPS, we can:

1. Segment the reponses based on written feedback from users who are detractors or passives (See the NPS Feedback section of the NPS dashboard).

2. Segment the responses based on the feedback category to analyze what requested product enhancements equate to the lowest NPS scores from users.

3. View overall number of responses by feedback category.

Renewal Metrics Reporting

Renewal Metrics in simple terms:

• Available Renewals (X): Total dollar amount of licenses ending is in the Renewal Qtr

• Renewal Rate (Y%): Total Won Amount ÷ Available Renewals where:

  • Won Opportunity License start date falls in the Renewal Qtr

  • Won Opportunity Product Line Type = 'Ren'

  • Won Amount <= Available Renewal Amount

• Forecasted Renewal Rate (Z%): Won Amount + (Total Open Amount * Probability) ÷ Available Renewals where:

  • Won & Open Opportunity License Start Date falls in the Renewal Qtr

  • Won & Open Opportunity Product Line Type = 'Ren'

  • Won & Open Amount <= Available Renewal Amount

• Target (A): Target Total Bookings set for the Renewal Qtr by Finance

• Actual (B): Total Bookings Won in the Renewal Qtr where Product Line Type = 'Ren'

• Target vs Actual aka TvA (C%): Actual ÷ Target

Renewal Target vs Actual (TvA)

• Calculation: Renewal Actual ÷ Renewal Target

• Renewal Target

  • Target set in a given period (Mo, Qtr, FY) by Finance

• Renewal Actual

  • Total Bookings Won in a given period (Mo, Qtr, FY) where Product Line Type = 'Ren'

Renewal Rate (Bookings)

• Calculation: ∑ Gross Renewals ÷ ∑ Available Renewals

• Available Renewals

  • Amount up for renewal at Account level by Qtr

• Gross Renewals

  • Renewal amount booked (up to Available Renewal Amount) where License Start is in a given Qtr

  • Calculation: MIN(Available Renewals,Renewal Bookings)

  • Example 1:

    • Account: Account 1

    • Available Renewals Q4: $100k

    • Renewal Bookings Q4: $130k

    • Gross Renewals Q4: $100k

  • Example 2:

    • Account: Account 2

    • Available Renewals Q4: $100k

    • Renewal Bookings Q4: $70k

    • Gross Renewals Q4: $70k

Forecasted Renewal Rate (Bookings)

• Calculation: (∑ Gross Renewals + ∑ Forecasted Renewals) ÷ ∑ Available Renewals

• Available Renewals (See Above)

• Gross Renewals (See Above)

• Open Renewal Amount

  • Renewal amount for open Opportunities where License Start is in a given Qtr

• Forecasted Renewals

  • Open Renewal Amount * Probability + Gross Renewal Amount (up to Available Renewal Amount)

  • Calculation: MIN(Available Renewals,(Open Renewal Amount * Probability + Renewal Bookings)

Support Tickets

Definitions

Ticket Status

• New: Ticket created that has not been assigned a support agent.

• Waiting on customer: The support agent asks the customer a question and is waiting for their response.

• Waiting on customer - Do not Close: Checkbox on the ticket. This is used for tickets that are expected to be open for a long period of time. This stops the clock.

  • Examples include: The customer requests that the ticket remain open after a solution is provided, the customer is on vacation, or the customer is out ill.

• On Hold: The support agent reaches out to an internal team and is waiting to hear back. Internal teams include Product, Development, or Customer Success. Any ticket that is tied to a Jira ticket is placed On Hold.

• Solved: Support agent provides a solution to the customer. A ticket remains in a Solved status for 48 hours before it is set to Closed. While the ticket is in a Solved status any response from the customer will reopen the ticket.

• Closed: If no response is recorded after 48 hours, a ticket in a Solved status will automatically be set to Closed. Any response to the ticket after that period of time will open a new ticket.

Ticket Level

• Level 1: Urgent Business Impact: Urgent issue on production system preventing business operations. A large number of users are prevented from working, and no procedural workaround is available.

• Level 2: High Business Impact: Major issue on the production system severely impacting business operations.

• Level 3: Normal Business Impact: Moderate issue causing a partial or non-critical loss of functionality on the production system. A small number of users are affected.

• Level 4: Low Business Impact: Minor issue on non-production system or question, comment, feature request, documentation issue or other non-impacting issues.

Ticket Measures

• First reply time: The duration between ticket creation and the first public agent reply on the ticket.

• Next reply time: The duration between ticket's first reply time and next reply time, unless otherwise communicated.

SLAs

First Reply Time - Premium and E20 only

Premium

• L1 (Urgent) - 1 hour

• L2 (High) - 2 hours

• L3 (Normal) - 8 hours

• L4 (Low) - 24 hours

E20

• L1 (Urgent) - 4 hours

• L2 (High) - 8 hours

• L3 (Normal) - 24 hours

• L4 (Low) - next business day

Next Reply Time - Premium and E20 only

Premium

• L1 (Urgent) - 2 hours

• L2 (High) - 4 hours

• L3 (Normal) - 24 hours

• L4 (Low) - 24 hours

E20

• L1 (Normal) - 4 hours

• L2 (High) - 8 hours

• L3 (Normal) - 24 hours

• L4 (Low) - 24 hours

CSAT

CSAT stands for Customer Satisfaction Rating. 24 hours after the ticket is set to closed, the end-user receives an email asking them to rate their experience. In the email the end-user is presented with the question "How would you rate the support you received?". Below the question is the option to select "Good, I'm satisfied" or "Bad, I'm unsatisfied" with the option to leave a comment about their experience.

CSAT Formula

Good, I'm Satisfied / Good I'm Satisfied + Bad I'm Unsatisfied

Active Servers (TES, TEDAS, and TEDAU)

TES

TES stands for Telemetry-Enabled Servers. It is the count of unique, production servers sending telemetry (“activity") data to Mattermost on a given date. Each component of TES can be described as follows:

• Telemetry Enabled:

  • Servers have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console.

  • Response to Mattermost's call to collect telemetry data recorded on a given date.

    • For a server to respond, it must be online and telemetry enabled.

• Servers:

  • Servers host Mattermost instances for teams and organizations.

  • Each team/organization can have one-to-many servers installed to host their instance.

    • Small/Medium teams typically leverage a single server.

    • Large teams can leverage Enterprise Edition features to create server clusters that allow them to scale their instance.

TEDAS

TEDAS stands for Telemetry-Enabled Daily Active Servers. It is the count of unique production servers sending telemetry (“activity") data to Mattermost on a given date with at least one daily active user.

A server is considered to have a daily active user, if at least one user recorded activity on the Mattermost server, such as viewed a channel or posted a message, in the last 24 hours.

TEMAS

TEMAS stands for Telemetry-Enabled Monthly Active Servers. It is the count of unique production servers sending telemetry (“activity") data to Mattermost on a given date with at least one monthly active user.

A server has a monthly active user, if at least one user recorded activity on the Mattermost server in the last 30 days, such as viewed a channel or posted a message.

Note that an update to the metric is considered to only consider activity in the last 28 days to remove weekday variation. However, this change would require in-product changes and thus has not yet been prioritized.

TES: Additional Metric Considerations

There are several ways to view the TEDAS metric, and there are several more ways to create metrics that are derivatives of TEDAS. Below are some of the ways to view, pivot, and/or filter the TEDAS metric to gather additional insights regarding the overall health of the business:

• TEDAS by First Telemetry-Enabled Date:

  • Provides the count of Telemetry-Enabled Servers trended by their first telemetry active date.

  • Is an indicator of how many New, Telemetry-Enabled Production Servers are being stood up on any given date, week, month, year, etc. throughout the history of Mattermost.

• TEDAS >= 7 Days Old w/ Active Users:

  • The count of Telemetry-Enabled Servers that are >= 7 days old since their first telemetry active date w/ >= 1 active user logged on the server.

• TEDAS Churn Rate:

  • The rate (percentage) at which Telemetry-Enabled Servers leave the platform (churn) or disable telemetry within a given number of days since the server's first telemetry active date.

  • Typically (as of 4/15/20), 75-80% of new, Telemetry-Enabled Servers churn within the first 7 days of their first telemetry active date.

Server Considerations

TES only measures the count of active production servers. The Mattermost.server_daily_details table is used to calculate TES and only contains production servers. Mattermost.server_daily_details is derived from the Events.security table.

The Events.security table logs all server responses to Mattermost's call to collect telemetry data. The Server type responses include test, development, and production servers. Conditional logic is used to filter out non-production servers from the Events.security table and insert them into the Mattermost.server_daily_details table.

• Logic to identify production servers within the Events.security table is as follows:

  • Mattermost Version matching recognized format

    • version LIKE '_.%._._.%._'

    • Other version formats are not valid because they indicate a test, development, or custom built instance.

  • No "Dev Builds" and "Ran Tests" recorded

    • dev_build = 0

    • ran_tests = 0

  • Registered Users >= Active Users

    • user_count >= active_user_count

    • Data anomalies occur causing servers to show active users > provisioned users - these servers must be excluded.

Non-production servers

Non-production servers are not included in TES calculations. Test and development servers are non-production servers that can be spun up for testing and various other use cases.

Server Age

The age of a server is determined by the server's first active date. This is the minimum date a response to Mattermost's call to collect telemetry data is recorded. It can be thought of as the server's first recorded telemetry-enabled date -i.e. first active date. The age of the server is calculated as a function of this date. It is the days between the server's first active date, discussed above, and the current date (or other relative date being used as a comparison to calculate server age at any point throughout its lifetime).

• Server Age = Current Date - Server First Active Date

TES, TEDAS and TEMAS Caveats

There are additional data quality issues within the Events.security table that need to be addressed before inserting the verified production servers and calculating TES, TEDAS or TEMAS. The Events.security table is supposed to contain 1 record per server per day. This is not always the case: ~2% of server IDs have multiple rows per day. To select a single record per production server we must:

• Identify the row per production server containing the maximum number of active users on the given date.

  • If the maximum number of active users = 0 then we select the most recently logged row based on the "hour" field value.

TEDAU

TEDAU stands for Telemetry-Enabled Daily Active Users. It is a metric that takes the rolling 7-day average of the sum of all "Active Users" logged by telemetry-enabled production servers on a given date. The TEDAU calculation sums the active_user_count column in the Mattermost.server_daily_details table, and then averages that value over the last 7 days.

TEDAU Events

Currently only a subset of possible events, dubbed "whitelist" events, count towards TEDAU. The reason only a subset of events are captured is a result of exceeding Segment's (third-party event logging service) row limit. In the future, event logging will transition to Rudder (another third-party event logging service), and the list of events that count towards TEDAU will become more expansive.

Deactivating a user in Mattermost will result in TEDAU decreasing, as deactivated users are filtered out of the statistic's query. However, reactivating a user in Mattermost will increase the TEDAU statistic.

TEDAU Caveats

TEDAU is the rolling 7-day average sum of active users for only verified production servers that are telemetry-enabled (described in this TEDAS section). All other servers, and their active user counts, are ignored as they represent testing, dev, and one-off user case environments that skew the results.

Telemetry-Enabled Active Users vs. TEDAU Metric

The distinction between an individual server's Telemetry-Enabled Active Users and the TEDAU metric is important to note. Telemetry-Enabled Active Users are the collection of users hosted by a telemetry-enabled production server, that have visited the Mattermost site in the last 24 hours. The TEDAU metric is the rolling 7-day average sum of these users across all servers.

Server Activations

A Server Activation is defined as the first date a production server sends telemetry data to Mattermost. In order to send telemetry data to Mattermost, a production server must be set up and activated by the end user. When a production server is first activated its telemetry feature is automatically enabled, which sends security diagnostics information to Mattermost via Segment (soon transitioning to Rudder). The server will continue to send this information on a daily basis until this telemetry feature is disabled by a Mattermost System Admin. A server activation is only captured and counted on the first telemetry-enabled date associated with a specific server.

Monthly Active Users

Monthly Active Users (MAU) are users that have performed an event on or within 30 days of a given date. User events are triggered when a user interacts with the Mattermost platform from their desktop or mobile device. After a user performs an event, that user will remain in MAU for 30 days. After that time the user will fall out of MAU and be classified as "Disengaged".

MAU Engagement Lifecycle Segments

Monthly active users are categorized into Engagement Lifecycle Segments. There are five engagement lifecycle segments: "Persisted", "First-Time Active", "Reengaged", "Newly Disengaged", and "Disengaged". Each segment is derived from the timeline from when a user performs an event. Each Engagement Lifecycle Segment is defined as follows:

• First-Time Active: The first time a user performs an event on the Mattermost platform and is classified as a MAU.

• Reengaged: A user performs an event for the first time after >= 31 days of inactivity on the Mattermost platform.

• Persisted: A user that performed an event in the last 30 days that does not fall into "First-Time Active" or "Reengaged" MAU Engagement Lifecyle Segments.

• Newly Disgengaged: A user, that was previously in MAU, that has not performed an event within 30 days of their last event. A user is only "Newly Disengaged" on the 31st day of inactivity.

• Disengaged: A user, that was previously in MAU, that has not performed an event > 31 days of their last event. A "Newly Disengaged" user becomes "Disengaged" on their 32nd+ day of inactivity.

MAU Considerations

Server Retention

Server retention is calculated as Day N retention, which shows the percent of users who return to the app on a specified day after their first launch.

We do not use rolling retention, which shows the percentage of users who return to the app on a specified day or any day after that. The reason is that rolling retention continues to increase as days go by (someone who comes back to the app on day 31 will count towards day 1, day 2, up to day 31 retention).

For concrete examples, a server is included in:

• day 1 retention, if there is activity 24-48 hours after server creation

• day 7 retention, if there is activity 168-192 hours after server creation

• day 14 retention, if there is activity 336-360 hours after server creation

• day 28 retention, if there is activity 672-696 hours after server creation

Trials

Trial Requests

All Trial Requests

• Number of trial license requests via https://mattermost.com/trial.

Enterprise Trial Requests

• Number of trial license requests via https://mattermost.com/trial from Named Accounts or Enterprises with 5,000+ employees, in America, EMEA, Australia, or Japan.

Note: Pull Requests for updates to this page need to be signed off by both CFO and CEO in the PR process.

Who can sign on behalf of the company?

Company agreements should only be signed by CEO, Ian Tien, or CFO, Kendra Niedziejko, with the following exceptions:

• If you are on-site and need to sign an NDA to enter a facility you may sign such an agreement.

• The following agreements may also be signed by the VP Legal, Nirosha Ruwan:

  • Non-Disclosure Agreements.

  • Data Privacy Agreements

• The following agreements may also be signed by the CFO, Kendra Niedziejko.

  • Unmodified Order Forms where the Customer is requesting a Mattermost signature.

  • Vendor contracts.

• Any contracts with terms that could have material impacts on financing or M&A transactions may only be signed by the CEO (e.g. non-standard liability, indemnification or inability to assign the agreement).

Who can send contracts for signature?

The following staff are approved to send contracts to be e-signed:

Approved Mattermost staff

• Lynn Conway - Primary for staff agreements

• Amy Nicol - Primary for vendor contracts, consulting agreements, and corporate agreements

• Nikki Johnson - Primary for sales agreements and customer supplier forms

• Jeff Dynda - Approved vendor contracts from legal and customer supplier forms

• Natalie Jew

What are e-sign completion expectations?

• E-sign request sent on weekdays before 4pm Palo Alto time should be signed by 9pm Palo Alto on the same day and if sent on a weekend signed by 9pm Palo Alto time on the following Monday provided one of the following is true:

  • For e-sign from Mattermost staff member: The e-sign is sent by a Mattermost staff member and must have Legal approval. E-signs sent from approved Mattermost staff are preferred since they are archived automatically in our e-sign system.

  • For e-sign from outside the company: The e-sign is prepared by a non-Mattermost staff member (potentially a vendor, partner or customer) and Legal approval is provided via email to Ian Tien and Amy Nicol ideally ahead of receiving the e-sign request.

    • Within 5 business days of the e-sign completion the contract owner or Mattermost staff submitting for signature should send Amy Nicol a link to the Box.com URL containing the fully executed signature to confirm the archiving of the contract is complete, since archiving is not automatic.

      • Note: E-sign requests from non-Mattermost staff are automatically filtered to a spam folder and the spam filter needs to be searched to find the request.

• If the timeline is urgent, or if the e-sign isn't completed by the expected timeline please send Ian Tien and Amy Nicol a Group Direct Message on the Mattermost server to expedite.

How to wet sign an agreement

• A "wet sign" agreement requires printing and physically signing paperwork with a pen, which is required by some regulatory bodies.

  • Culturally, it is important we have a smooth, clear process that makes physically signing paperwork in a remote company almost as easy and error free as signing in a physical office.

• Wet sign process

  • The wet sign process should follow the same workflow process as an e-sign process in terms of oversight and approvals, but instead of running the final e-sign a physical signing packet should be created with:

    • Two copies of printed paperwork to be signed.

      • Each should have sticker labels indicating what is needed to sign, so nothing is missed.

    • A pen.

    • Appropriate envelopes and/or UPS mailing labels to send the signed package on after it is received.

Self-Serve Analytics Metric Definitions

The document linked below has been created in hopes of creating a more self-serve Analytics infrastructure for product, product managers, and other employees to perform their own analysis. It provides up-to-date metric definitions, as well as Looker links to pre-filtered jumping off points for modeling the data. This documentation was presented in series of Self-Serve Analytics workshops that were hosted in early June FY22. A recording from the workshop has also been provided below for additional context.

MLT Metrics

This section outlines metric definitions maintained by finance for reporting to investors.

1. These are metrics for MLT discussions

   1. Any metrics shared by a department with the MLT will be asked to work with business operations to define the metric to be listed on this page under standardized naming and MLT definition checklist

2. Definitions center around ARR, GMA Magic Number and NPS

MLT definitions checklist

1. Qualifiers precede metrics names

   1. i.e. use ""Gross Margin Adjusted Magic Number" instead of "Magic Number, Gross Margin Adjusted" to avoid ambiguity when label names are truncated

2. Metric names should only have one possible interpretation

3. All MLT Metrics should have a unique acronym shorter than 8 characters

   1. Metrics will inevitably be shortened, pre-emptive definition avoids collision

ARR

Revenue Metrics

50% complete

• New ARR: ARR from new logos signed, with license start dates in the respective period.

• Expansion ARR: ARR from existing customers with a cross-sell/upsell deal, with license start dates in the respective period (e.g. increased licensed seat count, upgrading from E10 to E20).

• Contraction ARR: Reduction in ARR from existing customers, but where they are still paying Mattermost based on date of license change.

• Churn ARR: Reduction in ARR from an existing customer where they are no longer paying Mattermost based on the license end date.

• Total ARR: Total ARR ending in a specific period.

• IARR: Incremental Annual Recurring Revenue: (New ARR + Expansion ARR) - (Contraction ARR + Churn ARR)

• Count of New Logos (1%): Count of new logos signed, with start dates in the respective period.

• Count of Churned Logos (1%): Count of logos lost where an existing customer is no longer paying Mattermost.

Active Servers

50% complete

• Monthly Server Downloads: Number of successfully completed unique TE + EE downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget / curl downloads.

  • Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.

• Monthly Enterprise Account Server Downloads: Number of Monthly Server Downloads among companies and organizations with over 5,000 employees.

• New Monthly Server Downloads from Named Enterprise Accounts (1%): The first contact or lead from a Named Enterprise Account who were attached to an opportunity either manually by an AE or by Marketo, and who provides a business email on mattermost.com/download after downloading the Mattermost server binary. Excludes Salesforce account types equal to Customer or Partner.

• TEDAS: Telemetry Enabled Daily Active Servers: _**_Number of unique servers that have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console, and send telemetry “activity data” (such as number of users).

Active Users

10% complete

• Total Active Users: The total number of user accounts created on a single Mattermost server. Excludes deactivated accounts, deleted accounts and bot accounts. This is also the “Total Active Users” measure shown in System Console > Site Statistics.

• Registered Authorized Users: Same as Total Active Users.

• Total Registered Users: The total number of user accounts created on a single Mattermost server, including deactivated and deleted accounts.

• DAU: Daily Active Users: The total number of users who viewed the Mattermost site in the last 24 hours. Excludes bot accounts. This is also the “Daily Active Users” measure shown in System Console > Site Statistics.

• TEDAU: Telemetry Enabled Daily Active Users: The total number of users averaged over the last 7 days, who viewed the Mattermost site in the last 24 hours from servers that have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console, and send telemetry “activity data” (such as number of users). Excludes bot accounts.

• MAU: Monthly Active Users: The total number of users who viewed the Mattermost site in the last 30 days. Excludes bot accounts. This is also the “Monthly Active Users” measure shown in System Console > Site Statistics.

• Active User Count: A measure of the number of active users last 24 hours. Legacy measure, do not use this for analysis or decision-making.

GMA Magic Number

Gross Margin Metrics

1% complete

• GMA Magic Number: Gross Margin Adjusted Magic Number (1%): Net New ARR in a period multiplied by Gross Margin in the period, divided by total Sales & Marketing expense in prior period.

• NGMA Magic Number: Non-Gross Margin Adjusted Magic Number (1%)

• Gross Margin: Net sales revenue minus cost of goods sold

  • Net Sales Revenue:

  • Cost of Goods Sold:

Website Traffic

50% complete

• Organic Traffic:

  • Organic Web Traffic: Monthly unique visitors to *.mattermost.org, *.mattermost.com who originate from non-paid sources.

  • Organic Search Traffic: Monthly unique visitors to *.mattermost.org, *.mattermost.com who originate from an organic Google search.

Qualified Leads

1% complete

• MQL: Marketing Qualified Lead:

• PQL: Product Qualified Lead: Installed free TE/E0 version from a Target Account interested in EE features.

NPS

Contributors

10% complete

• 90s Hiring vs Goal (P0, P1, P2): Difference between hiring plan and hires broken out by priority level (P0, P1, P2), function and time.

  • P0 - Roles which hiring managers have flagged as high need.

  • P1 (1%) - Roles which hiring managers have flagged as medium need.

  • P2 (1%) - Roles which hiring managers have flagged as nice-to-have.

• • Note: Excludes translators, integration/solution creators and QA/UX contributors, as we don’t currently have a good way of measuring these contributors.

• Monthly Code Contributors: _**_Number of unique contributors in a given month who have committed at least one line of code to any of the publicly available Mattermost repositories on GitHub, excluding members in the Mattermost GitHub organization.

Product

50% complete

• • End User Product NPS: The Product NPS calculated among end users only (ie. not among Team or System Admins).

  • System Admin Product NPS: The Product NPS calculated among System Admins only.

  • EE Product NPS: The Product NPS calculated among all users in licensed E10 or E20 servers only.

Customer Success

1% complete

• Customer NPS: Customer satisfaction of the product, calculated based on single question “How likely are you to recommend Mattermost to a friend or colleague?", sent two days after booking or renewal is closed. The score is based on a -100 to 100 scale.

• Support Metrics (E10 and E20): Metrics calculated based on Zendesk tickets opened by E10 and E20 customers. Tickets opened by non-subscribed organizations are not counted towards these metrics.

  • Tickets Created: Number of net new Zendesk tickets created.

  • First Response Time [Median, hours]: The median number of hours from when a ticket was opened in Zendesk to when the first response was sent to the customer.

  • Resolution Time [Median, hours]: The median number of hours from when a ticket was opened in Zendesk to when the ticket is resolved.

  • % Resolution Time >7 days: % of newly opened Zendesk tickets whose first resolution time is greater than 7 days.

  • % Resolution Time >14 days: % of newly opened Zendesk tickets whose first response time is greater than 14 days.

  • Number of CSAT Responses: # of new CSAT (Customer Satisfaction) survey responses from customers whose Zendesk ticket was resolved.

  • Customer Satisfaction Score: % of newly submitted CSAT survey responses who responded “Yes” to the question .

Best Practices

To be added.

DRI for this page is Jason Blais

This page provides processes and guidelines for publishing in our public web properties.

The goal is to have clear public web properties where it is easy to find solutions to problems or questions you have for each of our audiences:

• Staff to do their work effectively.

• Users (including developers, administrators and end users) and Buyers to easily adopt and purchase Mattermost.

• Contributors to easily contribute to Mattermost.

Principles

Trust

• Consistent experience across public sites, including brand and voice.

• No inaccurate information.

• No "dead ends" where the user does not have a pathway to continue.

• No confidential information.

Growth

• Effective self-service where anyone can find solutions to problems or questions starting from a Google search.

• Scalable processes and guidelines that empower everyone to contribute.

Iteration

• Iteration over completeness, with constant openness to feedback.

Directly Responsible Individuals

Below are the tentative directly responsible individuals (DRIs) and success measures for each of our audiences:

Please read the following articles to learn more:

This page provides publishing guidelines, including

Voice and tone

Our voice is informed by our foundation as a messaging platform for Enterprise Developers and DevOps, but respects that our client base spans many types of organizations. Writing is one way we can bring Mattermost’s values to life. And above all, our voice demonstrates our deep respect for our clients and users. Ultimately, Mattermost exists because of them, so it’s important we keep their needs at the forefront of our writing style.

Mattermost's voice is:

• Clear

• Concise

• Consistent

• Customer-centric

• Professional

To achieve this, we keep the following principles in mind when writing content:

• Write clearly and concisely - get to the point quickly without losing valuable information

• Use simple, plain language that is easy to understand and family-friendly

• Avoid jargon and overly technical terminology

• Use direct, casual tone instead of an informal tone

• Use the active voice

• Write short, active sentences and maintain a visual separation between page elements

• Focus on what the target audience wants to accomplish by being practical/outcome-focused

• Write for an international audience without idioms or expressions that people outside of your country/region are unlikely to understand

We generally avoid the following statements and phrases as they're overused and vague:

• "Work better"

• "Do better work, faster"

• "Get more done in less time"

• "Chat" (as a stand-alone feature reference. However it is ok to use chat when describing a benefit "Create a Jira ticket without leaving your chat window." )

• "DevOps teams"

• "Utilize" (instead, use “use”)

• "High performance teams"

• Phrases that directly praise ourselves: “We’ve built an intuitive workplace messaging solution.”, “It’s a joy to use.”

The appropriate tone differs across different mediums. We don’t write technical and help documentation with the same tone as website copy or educational content. You can vary your tone to fit the situation, just as you’d talk to an angry person with a different tone than with an excited child. Voice is to tone as climate is to weather.

The Mattermost voice remains the same, even when the tone varies.

More information

Below is a set of guidelines on what information is considered confidential and should not be published publicly:

• Financial information related to Mattermost, such as revenue and cash, as this may impact potential future funding and IPO.

• Usage metrics and analysis related to Mattermost deployments (such as telemetry, trial conversions, DAU) as this may impact potential future funding and IPO.

• Personal information related to staff, customers or community, including residence and full name unless otherwise publicly disclosed.

• Customer information received during support or sales discussions, including customer name unless usage of Mattermost is otherwise publicly disclosed.

• Open discussions about security vulnerabilities, as this may put our users at risk of security attacks.

This page is a work in progress.

Areas of ownership

Below is a summary of our public web properties, including their target content, publishing system and areas of ownership:

Information architecture

Below is the tentative top-level information architecture for each of the above domains, work in progress.

handbook.mattermost.com

The handbook is developed with the following structure:

• About Mattermost, including mission, vision, leadership principles, company, and history

• Culture, including our remote-first culture, standards, and MatterCon

• Join Us, including why to work at Mattermost and open positions

• Onboarding, including guides for new staff and managers

• Operations, including mindsets, cadences, metrics, and definitions

.../docs

Since much software follows recognizable patterns these days, product documentation is shaped into familiar schemas. This often takes the form of product areas/topics, or common use cases.

Thus, information architecture is organized by topic or use case, such as below (exact architecture yet to be determined):

• Install and Configuration

• Deployment

• User Management

• System Administration

• Account Settings and Notifications

• Integrations and Plugins

• RESTful API

• Customization

.../education

Here, the focus is on providing learners access to content by their learning style and provides a mechanism with a currently limited scale of content. It is divided into three categories:

• Guides

• Videos

• Courses

From here, further organization based on themes (informed by persona use cases), as content is made available.

Later, as content evolves, content may be based on particular personas and their learning paths.

.../community

A sample architecture for contributors may look like:

• Contributor Process

• Translations

• Documentation

• etc.

.../support

No information architecture is yet defined, but in general it will consist of:

• Support Resources (including peer-to-peer forums)

• Knowledge Base FAQs

mattermost.com

The Mattermost website is developed with the following architecture:

• Product, including features and integrations

• Pricing

• Solutions, including use cases

• Case Studies

• Resources, including training and blog

• Docs, including installation and configuration

The Mattermost logo

The logos below are available for use in your integrations and applications that connect to Mattermost. Use of the logo is permitted as long as it’s used in a non-commercial way and does not imply endorsement by Mattermost, Inc.

The Mattermost logomark is called "the instrument". It represents four tools that organizations need to achieve their highest priorities:

• A compass for direction

• A clock to set pace

• A meter to measure output

• A dial representing inputs — the contribution of everyone on the team

Logo variations

The Mattermost logo is available in vertical, horizontal, and logomark-only versions. The logo can be represented in black or white as displayed below.

Horizontal Logo: Min size 100x16px

Vertical Logo: Min size 70x39px

Logomark: Min size 16x16px

Usage guidelines

Clear space

To ensure an uncluttered presentation, always maintain a full "X" space around the logo. The "X" height is always the height of the lowercase letter "m" in "Mattermost". Use the safety area as an invisible border.

Misuse

Please use the Mattermost logo with care. Don’t alter the Mattermost logo in any way:

• Don’t redraw the logo.

• Don’t warp the shape.

• Don’t recolor the logo.

• Don’t apply effects.

• Don’t crop the logo.

Make sure you’re using the correct version: some old and distorted versions from the past exist and should be replaced.

Logo downloads

Brand guidelines

Name usage guidelines

Using the Mattermost name is generally permitted as long as it’s used in a non-commercial way and does not imply endorsement by Mattermost, Inc.

• Please do not name your integrations or apps starting with, or only using, the name "Mattermost", as this may confuse end-users as to where to find support.

Community projects might be named using "for Mattermost", examples:

Alternatively, community projects may concatenate names containing Mattermost, for example:

Exception: Please don’t use the name “matterbot”, as that is an internal service under development.

Company short description

Mattermost is an open source platform for secure collaboration across the entire software development lifecycle.

Hundreds of thousands of developers around the globe trust Mattermost to increase their productivity by bringing together team communication, task and project management, and workflow orchestration into a unified platform for agile software development.

Founded in 2016, Mattermost’s open source platform powers over 800,000 workspaces worldwide with the support of over 4,000 contributors from across the developer community. The company serves over 800 customers, including Samsung, Nasdaq, SAP, European Parliament, and the United States Air Force, and is backed by world-class investors including Redpoint, YC Continuity, Battery Ventures, and S28 Capital.

To learn more, visit www.mattermost.com.

The Tech Writing team is responsible for maintaining the Mattermost Documentation site and stewarding the quality of other Mattermost knowledge and language repositories used within Mattermost products.

Areas of Ownership

• docs.mattermost.com

• Information architecture and quality of developers.mattermost.com

• In-product UI text

• Mattermost Product Translations

• Information architecture and quality of handbook.mattermost.com

The Data Engineering team is responsible for data warehouse and management.

Areas of Ownership

• Data warehouse & management

• Data Pipelines

• ETL scripts and data transformations

• Data connections to Looker, dbt

• Rudderstack, Snowflake, Airflow, Stitch

The Mattermost Handbook is a work-in-progress in that information is constantly being updated, added, revised, and edited.

Editing the Handbook

The Handbook is open to the public and edits can be submitted by anyone.

Adding content

You don't need to ask permission to add content to the Handbook. Follow the steps in How to update the Handbook to get started.

Questions, suggestions, bugs

If you have an idea for content, you can submit an issue detailing your idea. The more information you provide the better. That said, if you have content ideas why not add it to the Handbook, open a PR, and see where that goes.

Mattermost fiscal year ends on January 31.

As part of the yearly planning, we use various documents as references.

Below is a list of references used for FY24 Strategy & Plan (link to be added).

• Nov 2022 COM Presentation of Thematic Goal & Defining Objectives

• FY24 Message House

• FY24 Pricing & Packaging Principles

• FY24 Product Editions & Plans

• FY24 Company-Level Goal Tracker

• FY24 Prioritization Worksheet

• FY23 Strategy and Plan

• Simon & Kutcher Final Packaging Readout

• Simon & Kutcher Full Packaging Deck

• Redpoint metrics template

• MLX Areas of Responsibility

• Acronyms

R&D includes engineering, QA, product management, documentation, analytics, community, and design (UX, UI).

R&D Key Info

• Analyst Research: Analyst meeting tracker, briefing procedures, research. We are currently Gartner clients.

• Compete: Key articles on competitors. Also see automated feeds from competitor marketing.

What tools we use

We use a variety of tools at Mattermost. Not every team uses the same tools, and it can get overwhelming to try remember who uses what and where it is.

During onboarding you'll be provided with a list of tools to set up. You can also visit the Helpdesk to find the tool and request access.

Where to find information

We use a range of web properties and tools to document and share plans, specs, roadmaps, and release schedules.

• Product roadmaps, feature releases, planned features: Features by release productboard, Release roadmap by vertical.

• Product specs: Teams, Software project

• Apps, integrations, plugins: Integrate

• How to get started with contributing and developer set up: Getting started

• Designs and mockups: Figma

• How open source software is developed: Development & Release Process

• How contributors can get involved: Platform Contribution Process

• Analytics playbook and data wallows: Analytics

Where to find us

• Technical writers: DWG: Documentation Working Group

• Product Managers: Product Management

• UX team: UX Design

• Analysts: Analytics

• Community: Community Team

Tip: We generally use channel naming conventions to make it easier to find channels. Team channels are prefixed with "team", feature channels prefixed with "feature" and so on. For example, if you're looking for a team channel, open the channel browser and search for "team".

Who we are

R&D is led by:

• Corey Hulen - CTO

• Chen Lim - VP, Product

We use this spreadsheet to track the organization structure.

Mission

The Delivery team enables Mattermost Engineering to deliver products of high quality, secure, scalable, and efficient fashion to Mattermost customers. The team ensures that Mattermost scheduled, security, and patch releases are publicly released in a timely fashion.

Vision

By its own nature, the Delivery team is a backstage, non-user feature facing team whose product and output has a high impact on day to day development operations, quality and releases. The team creates the workflows, frameworks, tools, architecture, and automation for Engineering teams to see their work reach production effectively and efficiently.

Actions

• CI/CD blueprints, tooling & infrastructure for dev & testing workflows

• Automation test framework

• Automate release generation and reduce Release Manager toil work

• Improve security principles in Mattermost software supply chain

• Extend release environments to improve testing for Mattermost releases

Principles

• Guard and raise end-product quality standards

• Treat our work like a product

• Promote self-serve

• Aim to make our work easy to use

• Influence best practices

How we work

Reaching our Team

Every week we have a support rota who is responsible for troubleshooting any S1/P1 related issues.

Areas of Ownership

The team regularly works on the following tasks, in the order of priority:

• Ensuring continuous delivery of Mattermost products to SaaS and self-managed

• Participating in incident resolution and acting on corrective actions for SaaS and self-managed software delivery

• Minimizing the use of custom tooling by building or enhancing features within Mattermost

• Improving the robustness of SaaS software delivery by creating and improving tooling (release & testing)

• Coordination, education, and preparation of Mattermost releases for SaaS and self-managed users for the scheduled minor, patch, and security releases

• Review release metrics

Meetings

The Cloud Platform team is responsible for our Mattermost Cloud SaaS technology.

Vision

Enable everyone to build and deploy with high velocity in a self-served manner.

Actions

• Increase developer productivity

• Influence Cloud readiness

• Input driven decision making

• Encourage best practices and keep quality standards high

• Keep experimenting

• Keep documentation fresh

Principles

• Balance stability and experimentation

• Embrace teamwork

• Leave the room better than it was

• Data/Feedback driven to find the best solution

• Distributed systems, distributed team

• Be curious and keep learning

• Share knowledge and seek feedback

Ask for Help

If you need our assistance please use the following follow the General Workflow

We can also be reached out:

1. For support questions related to production you can reach us in ~cloud-support channel.

2. For all the other questions you can reach us in ~infrastructure-platform-team channel

How we work

General Workflow

1. Mattermost members open new issues in Platform Board

2. Every new issues goes through an Issue Triage weekly

Areas of Ownership

The team regularly works on the following tasks, in the order of priority:

• Ensuring provisioning, rolling out and controlling the workspaces fleet with an automated manner (eg. provisioner, k8s operator)

• Improving developer productivity with providing self-served capabilities for testing envs in cloud developer platform (eg. spinwick, cloud plugin)

• Ensuring and supporting other teams for cloud readiness (eg. Mattermost migrations, database connection pooling)

Meetings

Mattermost has three different roadmap views: Public Product Direction, Internal Roadmap, and a Release Plan. Each has a specific target audience and framed in different ways:

Public Product Direction

This view is external-facing, shared publicly with our users, community and customers. This is currently available on our website (https://mattermost.com/direction/).

The primary intent is to share the vision and direction of the product with no committed dates. We use it to highlight the benefits of what we’re building, so it’s easy for people to picture how what we’re building is going to make their Mattermost experience the best it can be. For an example of similar public product direction sites, see https://about.gitlab.com/direction/.

In addition to communicating the direction, we also include features framed in terms of estimated timelines on our productboard portal

• 3+ Months: This tab includes projects that are in progress now. We’re happy to get on calls to share updates and gather feedback on specs, designs, and prototypes.

• 6+ Months: This stage covers projects coming up soon, after some of the “Now” work is completed. If an item is in this category, we’re happy to have conversations validating requirements and use cases.

• Future Consideration: This stage includes features we’re considering for later. We’re happy to have conceptual conversations on these items, to see which problems resonate the most. We add and remove things from this category as we learn from those conversations.

Internal Roadmap

This view is internal facing, shared cross-functionally across Mattermost staff, to let people see how our product efforts tie back to the higher level company goals and strategy. Items on the roadmap are related back to objectives, and the objectives tie back to our Company Fiscal Year plan, so it’s easy to see how everything fits together.

Key distinction from the Public Product Direction is that this view is framed in terms of business goals (such as increasing NPS, ARR, retention) rather than benefits. Moreover, this view may include business initiatives such as the customer portal, technical, or telemetry efforts that are not outwardly beneficial to our customers.

Release Plan

We also create a release plan based on the internal roadmap. The purpose of the release plan is to enable project management for development teams. All dates in our release plan are target dates not commitments, and items are often moved, added, and removed from the list.

This view is internal facing, month-by-month release plan of new features.

Currently, the Release Plan can be found in productboard, and is updated weekly by the Product Management team.

Learn more about release plans.

In addition to GitHub Issues, we also use Jira tickets for managing chunks of work to be performed.

Ticket triage

Ticket triage happens within the team's normal sprint cycle. At that meeting, the team reviews all new tickets, assessing the scope, effort, and impact of each ticket. They make a decision on the priority of the ticket. Once it's decided in triage meeting that the ticket should be worked on, the ticket moves into the To Do state.

Ticket states

Tickets are in one of several states, and transition between states is typically linear. The beginning to end flow is described below.

Backlog

Ticket reach this state by being created. A ticket usually needs triage to proceed further. One notable exception is an urgent bug fix, which moves to "In Progress" as soon as the implementer has bandwidth to address the issue.

Will Do

Ticket reach this state by having been assigned a sprint (could be the "Queued" sprint) and having been identified in triage as something the team desires to achieve. Tickets in this state typically do not have anyone assigned to them. This state is synonymous with "Select for Development".

To Do

Tickets reach this state by being assigned to the implementer, who has clear intention to work on the ticket soon (within the next sprint or two). A ticket moves back to Will Do if the implementer no longer has present or future bandwidth to do the work in the ticket.

In Progress

Tickets reach this state by the implementer beginning to perform the work needed to finish the ticket. A ticket can be in progress for an indefinite period of time, but if tickets are routinely in progress across multiple sprints, it is likely a sign that the tickets need better definition or reduction in scope. A ticket moves back to To Do if the implmenter is no longer working towards completing the ticket.

Submitted

For tickets that require code changes, tickets reach this state by the implementer opening a pull request. Many tickets can be tested by QA at the time of the pull request. For such tickets, the QA steps to test and verify should be added to the ticket when moving the ticket to the "Submitted" state.

Tickets can be in submitted state indefinitely as long as forward progress is being made in the pull request review. A ticket moves back to In Progress if are too many issues with the pull request for it to make sense to keep the pull request open.

Done

Tickets reach this state by having a pull request merged. Once moved to this state, tickets trigger additional work to be performed by the QA team. Tickets move back into In Progress from this state if QA detects there are defects or regressions because of the work merged by the ticket.

A ticket could also move to "Done" from any state if it is decided that the work or change will not be performed or accepted. Common reasons for this include:

• The ticket is a duplicate of another.

• The ticket is no longer relevant.

• Priorities changed enough that the ticket will never be worked on.

• A bug ticket can not be reproduced.

• What is observed in the bug ticket is deemed acceptable behavior.

Close

A ticket reaches this state after QA verifies through testing that the change has been completed as anticipated.

Bugs are any “obvious errors” on how the product or a feature is functioning as well as any UI issues. If you’re not reporting an obvious error, please file a Story ticket instead. Errors on unsupported platforms are not considered bugs.

1. Check that you have permissions to create tickets in Jira

• If you don't already have a Jira account or permissions to create Jira tickets, you can request access through the Mattermost IT helpdesk.

2. Confirm you’re filing a new issue

• Search existing tickets in Jira's "Mattermost" project to confirm your issue isn’t already filed by someone else.

3. Confirm the bug is not a confidential issue

• If your issue involves security or if it involves confidential information or customer information, please mark the bug ticket as internal.

4. Information needed on Mattermost bug tickets

• Steps to reproduce: How can we reproduce the issue.

• Expected behavior: Describe what you’re expecting to see.

• Observed behavior: Describe your issue in detail. What did you see happen? Please include relevant error messages and/or screenshots.

• Severity: Choose appropriate severity from the drop-down. Severity levels and descriptions are documented here.

5. Additional helpful information

• Labels: Add a customer-bug label if the ticket is based on a customer bug report. Add a community-bug label if the ticket is based on a community bug report.

• Environment: There is an Environment field with drop-down options to choose whether the bug was found in Cloud test servers, Cloud production servers, Self-Hosted test servers, Self-Hosted production servers, Desktop app, Mobile app, or in Master/PR testing.

• Attachments: Please include screenshots and/or videos of any helpful error messages and snippets of what you are seeing.

• Possible fixes: If you can, link to the line of code that might be responsible for the problem.

• Regression: Please re-test your issue (if possible) on the previous Mattermost version at https://prev.test.mattermost.com to see if the bug is a recent regression.

• Add any additional relevant details if it helps make the bug more clear. For example, you can add details on Mattermost server and version, OS and version, Mattermost mobile app version, Mattermost desktop app version, and any notable Mattermost configurations (such as HA, Elasticsearch, image proxy, SSO).

6. Assigning new tickets to a team

• If you know which team would own fixing the bug, you can assign the ticket directly to that team.

• Otherwise, you can leave the team Unassigned and the Program Manager assigns the ticket. The Program Manager follows the ~Bugs channel on a daily basis.

Mattermost Software Requirements

This document provides guidelines for determining which software versions Mattermost requires. For past discussion on why these guidelines were chosen, see this conversation.

Current software requirements are documented here.

Before submitting software requirement updates to the documentation, the following steps have to be taken into consideration:

1. Check with Chen in the Analytics channel to see what % of users and what % of posts are made by the versions we’re considering to drop support for, to review potential impact to users.

2. For versions we are considering dropping support for, ask the customer support team what the impact is for customers (e.g. if there are known customers on those versions and if we get customer support tickets specific to those versions).

3. Ask developers what the impact is for us internally if we consider dropping or continuing support for a version.

4. If we decide to drop support for a version, work with product managers and developers to plan for updating the version information in all relevant places, including but not limited to: in the product itself (such as the mobile app), Changelogs and README GitHub pages.

Desktop Apps

PC Web

Mobile Apps

Assigning priority levels

Priority levels on Jira tickets should be filled in by the ticket reporter using the Priority field. The triage team will review and update priority levels based on the guidelines above.

Bug tickets are sometimes assessed on a case-by-case basis and further considerations may be applied, such as whether the bug is a recent regression or not, how risky the bug fix is, or whether it’s more effective to revert code that initially caused the bug.

Frequently Asked Questions

Why are we doing this?

• We want to consistently deliver high quality products and interactions with our customers. Priority guidelines enable us to prioritize and address quality issues that can erode trust in our brand.

Security dot releases are done for high, medium and low level severity security issues based on the backport policy. The general steps are:

1. A pull request for the issue is submitted and dev/QA reviewed, and then merged.

2. The bug fix is cherry-picked to the relevant release branch.

3. A release candidate (e.g. 7.2.1-RC1) is cut for quick final smoke tests.

4. After QA approval, a final release build is cut (e.g. 7.2.1) which is ready to be shared with the customer.

Please refer to the Dot Release Playbook for a most up-to-date checklist.

Mattermost ships with a new version once a month for both cloud and self-hosted customers.

Release numbering

Mattermost numbers stable releases in the following format: [Major Build Number].[Minor Build Number].[Patch Build Number]

Major build number:

• Purpose: Major system releases introduce significantly new functionality or change existing product behavior

• Release frequency: Once a year. Major system releases are infrequent

• Example: v1.x.x, v2.x.x

Minor build number:

• Purpose: Introduce new features, bug fixes and performance improvements

• Release frequency: Monthly cadence

• Example: v1.2.x, v1.4.x

Patch build number:

• Purpose: Patch existing releases when severe bug fixes or security patches are required

• Release frequency: As required

• Example: v1.2.5, v1.2.6

Objectives

The goal is to deliver value to users quickly by a) shipping fast to get features to customers quickly for experimentation/feedback, and b) iteratively behind feature flags as a protection if any issues arise. This document outlines the principles and guidelines for how we release a new update of each product line on a monthly basis.

Release Principles

1. Focus on High Impact by shipping every new feature and any riskier code changes behind a feature flag

   • Each development team is individually responsible for quality and deciding if a feature should be included in a release or not (with the release team giving guidelines). This may mean shipping more patch releases, but we can manage some of this by using feature flags. This also requires good test automation coverage.

2. Automate

   • Automate release processes and tasks.

   • Automate release tests and have E2E tests for features.

3. Earn Trust by communicating to external and internal stakeholders clearly

   • Enables us to make expectations for releases clear for all stakeholders.

   • Make expectations for each release clear (release dates, etc.). Communicate. Ensure that everyone on the team is familiar with the release processes.

   • Release notes, minimum version requirements, and any important upgrade notes need to be available for customers and communicated via docs, blog, emails, and channels.

4. Earn Trust by including all stakeholders (Tech Writers, Marketing, QA, etc.) early in the release process

   • Enables us to avoid missing key tasks and to avoid last minute work.

   • E.g. When opening a PR, add a “Docs/Needed” label for any PRs that need docs and communicate to Tech Writers. This ensures that we have time to complete docs on time.

   • Make tracking bugs and testing requirements easy. E.g:

     • Resolve Jira tickets for QA when PRs are merged (and cherry-picked).

     • Add QA test steps to Jira tickets and/or PRs.

     • Add Fix Versions and Milestones in Jira/PRs for bugs/tickets for easy tracking.

     • Add clear Release Notes on PRs.

5. Achieve Customer Obsession by doing retrospectives on release issues and monitoring customer/community release bug reports after releases

   • This allows us to learn from issues so that they don’t happen again and to fix critical bugs asap.

   • Retrospectives for issues and dot releases are important.

   • Monitor community and customer reports in GitHub, Forum, and channels like Ask PDE, in partnership with the Support team.

Release Cycles

Release dates communication

Release dates are currently communicated in the following ways.

1. Channels
2. Mattermost Release Dates Calendar

   • Lists key release dates and deadlines.

3. PM and PDE meetings

   • Updates are provided on upcoming key dates and/or features as needed.

4. Productboard
5. Spreadsheet

Plugin Release Processes

Tracking feature flags

Adding milestones on PRs and Jira tickets

• If the PR is scheduled for a specific Mattermost release, please add the Cherry-pick Approved label and self-managed milestone on the PR. The Release Manager keeps track of PRs with the Cherry-pick Approved label and self-managed milestone on a daily basis.

• The Release Manager also tracks regression bugs and aims to ensure that they get fixed for the next release.

• A fix version is added in Jira to track regression bug fixes for Mattermost releases.

Triaging Mattermost customer issues

When triaging a bug report, consider the following:

• Impact of the bug on customers.

• Severity of the issue.

• Risk and effort of reverting to the last version or fixing a bug.

Criteria

1. "We need to revert to the last version" process:

   • Crash or all services are down due to a bug; affects some to all Mattermost Cloud customers.

2. "We need to release this ASAP" process:

   • A severe regression or loss of functionality; affects some to all Cloud customers.

3. "It's OK to wait until next release" process:

   • Loss of function, but little impact on Cloud customers.

Responders

• Who is making the decision on which process above we need to follow?

  • In some cases it's the customer support teams or Cloud teams, and in some cases it's other people such as the Release Manager or developers who notice or get notified about the report.

• Bugs will be fixed by either the CRE team or by respective development teams, depending on availability and expertise.

Frequently Asked Questions

Q: What is the release cycle for the React Native mobile apps?

• A: The mobile apps follow the same monthly release cycle as Mattermost Server/Webapp, releasing on the 16th of each month.

Q: What is the release cycle for the Mattermost Desktop app?

• A: Desktop releases are shipped every 3 months starting in March, 2023. For more details, see https://handbook.mattermost.com/operations/research-and-development/product/release-process/desktop-release.

Q: When do I need to have a feature PR to be included into the next release?

• A: Aim to have the PR merged before the Feature Complete deadline. The earlier in the monthly cycle the PR is merged, the higher the chances are for it to be included in that month's release. The quality of our releases is important and feature PRs are not normally cherry-picked to a release branch.

Q: How can I determine if my merge request will make it into the next release?

• A: The Release Manager adds PR milestones and Jira fix versions for tracking. You can also check the release branches (e.g. in the mattermost repo) to see what's included.

Q: Do we use Playbooks for releases?

• A: Yes, playbooks are used for cloud & self-hosted, mobile and desktop releases, and for dot releases and plugin releases.

Q: How are PRs merged for release?

• A: PRs are first merged to master. As needed, the dev who submitted the fix is also responsible for cherry-picking it to the release branch after a release branch has been cut.

Q: How is cherry-picking done?

Q: What version is community.mattermost.com kept on?

• A: Normally on master branch and it updates daily.

Q: How to remove a feature/bug from a release?

• A: The feature flag is turned off. Another option is reverting the feature from the master and release branches.

Q: How are NOTICE.txt PRs submitted?

• A: PRs are first merged to master. The dev reviewer is responsible for helping cherry-picking it to the release branch as needed.

Q: Is an improvement a feature or a bug?

• A: Usually features/story tickets.

Q: How does release team monitor what changes went into a release?

Q: How does translations branching work?

• A: The translation PR will be submitted against the master branch.

Q: What is the process for community PRs?

• A: Review, merge, and cherry-pick as needed.

Q: What information does the Customer Support team need for Cloud releases?

• The Announcements channel in the Staff team is used for release updates and for posting the changelog.

Mattermost core team works on a monthly release process, with a new version of cloud and self-hosted shipping successively once a month.

A single release is qualified for both cloud and self-hosted at the same time, with both versions labelled as vX.Y.Z. Outside of patch releases, no changes are released to self-hosted customers before they are first released to cloud customers.

Release Timeline

• Feature Complete and Release Branch Cut at T-24

  • All major features must be complete and merged approximately five weeks prior to the self-managed release date. Prior to this day, the release manager makes sure everyone is aware of the impending deadline by posting reminders in the Release Announcements and Release: Self-Hosted & Cloud channels and messaging team leads. If any pull requests are not merged by this date, then the release manager changes release milestones in Jira after checking with team leads that those features can be pushed to a future release. Updates to prepackaged plugins should also be complete and merged by this date, with room to address bugs before code freeze. This is also the date when the release-X.Y branch is cut from master. Any additional changes to the release must first be merged to master before being cherry-picked to release-X.Y. All test servers are configured to update daily from this branch.

• Judgment Day at T-19
• Release Qualification Starts at T-18
• Code Freeze at T-10

  • Ten business days prior to the release date, and near to the end of release qualification, code freeze prohibits all further changes to the release branch. No further code changes will be accepted, preventing last-minute regressions, fixes, and additional testing. A final release build is cut and pushed to https://github.com/mattermost/mattermost, but marked as pre-release. The delivery team continues to triage and push minor bugs to the next release.

  • If a showstopper issue is found, a patch release is required that may risk the remaining milestone dates. Minor bugs or issues found after code freeze should generally be deferred to the next release, but it is occasionally necessary to patch the monthly release to address show stopper bugs or security issues. Introducing a patch increments the patch version (vX.Y.Z+1) and may delay the cloud or self-hosted release dates. We bump the patch version here to preserve the integrity of the code freeze deadline. We also schedule a retrospective to better understand how the issue was introduced and discovered so late in the release cycle.

• Release Approval at T-8

  • Approximately two weeks after starting release qualification, the delivery team formally signs off on the complete release qualification.

• Cloud Beta Release at T-7

  • The qualified release is rolled out to the cloud beta production servers for final QA smoke testing.

• Cloud Freemium Release at T-6

  • After final QA release approval, the release is rolled out to the freemium ring.

• Cloud Professional Release at T-5

  • Two business days after soaking in cloud beta, the release is rolled out to customers in the professional ring.

• Cloud Enterprise Release T-3

  • Once stabilized in cloud professional, the release is rolled out to customers in the enterprise ring. The actual date may be two or three business days later to avoid releasing to enterprise customers on a Friday.

• Cloud Dedicated Release at T-2

  • Once stabilized in cloud enterprise, the release is rolled out to enterprise customers with dedicated clusters. As with T-3, the actual date may be one or two business days later to avoid releasing to dedicated customers on a Friday.

• Self-Managed Release at T-0

  • On the first business day on or before the 16th of the month, the same build already qualified in cloud is released for self-hosted customers. No rebuild is required. Marketing communications begin to roll out, and the release is communicated on the blog and other marketing channels. The pre-release bit on the corresponding GitHub release is manually removed. Note that this may be vX.Y.1 or a later patch release if fixes were required after code freeze. Release documentation, including the changelog, is merged on this day.