Question of the Week!

[Laura_McCarthy]

Today marks Airtable's second Question of the Week 🎉 Special shout out to @Ben_Young1 for kicking us off last week with his insightful response. 

This week's question is What's your best tip on how to introduce a new Airtable base or workflow to your team? We look forward to reading through each answer. 

Enjoy the rest of your week and have a fantastic weekend! 

Airtable Community

[KWU]

When I’m rolling out a new Airtable app for my team, I break down the problem into different buckets:

1. Communication plan - Does my team understand why we’re rolling out a new app or workflow? Does my team understand the timeline for how we’re rolling out the new app, which training calls they can join, where to find resources, how to reach out for help, etc?
2. Onboarding and education - A series of live or pre-recorded training sessions to walk my team through the app, data model, views, interfaces, automations, and overall workflow design. The goal here is to show huge improvements over existing workflows and methods of getting work done. Make this fun.
3. Rapid iteration and feedback - What is the strategy for quickly addressing feedback from team members who run into issues or come up with ideas for improvement? How fast can make improvements to our app? How do we manage the deployment of major changes over time?

Most people don’t like new things. New things require time to learn. New things introduce risk. New things can be scary. So I think the goal of any new tool or process introduction is to really reduce these concerns and emotions as much as possible and make the team feel like they will be supported throughout the entire process.

No one is going to adopt a new Airtable app if they don’t see the value. So we have to show the team, from their perspective, the benefits of using the app. And if we can sprinkle in moments of delight, even better!

I also highly recommend creating a resource area where people can go to find things they need asynchronously. There are two ways to do this in Airtable. The first is to use the Base guide area which can be found by clicking on the name of the base:

The other way is to use Interface Designer to build an onboarding guide.

Hope this helps!

[Elza_Lambergs]

+1 to @KWU's tips! If you just consider those three buckets, you’re already in a great spot. 

As he mentioned, new things are scary for people. In my experience, the top question on everyone’s mind is “What’s in it for me?”.  Here are a few strategies that have helped me get ahead of questions like this one:

• Find your champions: You don’t have to do this alone! In fact, your new app is more likely to be adopted if you identify a few champions across your team. They can help you craft a stronger communication plan, anticipate specific questions, and hopefully just make the process more fun. Our guide is a great resource if you’re not sure how to go about this step.
• Set up a communication channel: Whether it’s Slack or recurring office hours, give your team a clear place to ask their in-the-moment questions. This resource will help them feel safer and more supported through the rollout. Bring your champions into the channel to help out.
• Build a living FAQ resource: Use the questions your team asks to build a FAQ page that grows over time. Better yet, just add a new page to Kevin’s onboarding interface. Promote this page and save yourself time when someone undoubtedly asks you the same question again. 😉

Hope this sparks some ideas! Launching a new workflow is so different from team to team, so I'm very curious to hear how others have approached this 👀

[Tobias_LGKR]

@Laura_McCarthy That's a really crucial topic. We really do it hands on and by the seat of your pants. We only have 4 users at the moment so I am constantly developing, improving, changing as we grow on a day to day basis. I try to communicate these changes as good as I can. Sometimes everyone just has to figure it out by themselves.

It would be really helpful, if there were something like a "change log" function in Airtable on the user level. Let's say I make changes in an interface. I could make a quick documentation of these changes when I am finished and the next time a user logs on to that interface a window pops up with my message about those changes. The obvious then would be a change log page, where those announcements are archived.

[KWU]

Super helpful tip and great product suggestion. You should add this idea to our ideas section!

[kuovonne]

In reply to Tobias_LGKR's comment ...

> It would be really helpful, if there were something like a "change log" function in Airtable on the user level.

Most of this could be done using existing features.

Create a [Change Log] table in your base with a rich text field for the announcement and a multiple-collaborators field {Viewed By} to hold which users have viewed the announcement. Then have an interface page showing the records from the [Change Log] table, showing records where the {Viewed By} field does not include the current user.

When a user is done reading an announcement, he adds himself to the {Viewed By} field.

I expand more on this idea here.

[Laura_McCarthy]

@kuovonne Thank you for sharing your expertise and insight around use of existing features within Airtable.

[Ben_Young1]

Some Quick Background

Two weeks ago, on the 9th, I sat with my finger over the Post Your Comment button on this question. I wrote this out but ultimately didn't post it because it didn't align with how y'all intended the question to be answered. I was prepared to let it die in my countless drafts. I also write a lot. Judging by the lack of additional engagement on that previous thread, it might kill engagement if I posted a full-length think piece. 
I still feel weird about posting it, but when I read this week's question, my mind fell back to the same train of thought, so I'm more willing to post this after everyone has moved on.

My Original Post

If I've built a base or solution for a team and have to introduce it to them, something has gone very wrong. I aim to keep my stakeholders at the core of what I build for them. If I achieve that, they will almost instantly feel at home in what I've created.

In practice, I have two critical ideas that I keep in mind when I'm building in Airtable. I'll explain these two concepts and how I've been applying them in my Airtable work.

A couple of years ago, I sat alone in the office at 8:30 pm.
I had just discovered Airtable. I was enthralled. I started building. I started importing. The memory of it all coming together so fast in those early weeks is enough to get me excited just thinking about it. It didn't take long for me to start getting the rest of my team to collaborate in Airtable.
Everything was going so strongly... until it wasn't. People stopped logging in. Data went stale. Excitement eroded. 
It wasn't long until I encountered revived spreadsheets and decks being passed in email threads again. I took this as an indication that there wasn't enough in Airtable. That this meant I needed to build more.
I spent more hours increasing the complexity. More dependencies were added. The automations grew.

I wrote documentation. I made Loom videos. I wrote Base Guides. I held training.
This was the start of a vicious cycle for me, culminating in a much-deserved (yet still painful) burnout.

Sustainability

To break this cycle, I had to start by finding the answer to this critical question: Why were users not using the solutions I built for them?

I won't leave you hanging. The answer is that I wasn't building for them. I was building for me. If I knew something could be made, I never considered whether it should be built.
I kept creating, building, refactoring, and adding without knowing when I could say that my work was completed.
Sure, it meant I produced an impressive, incredibly robust database that could theoretically support a modestly sized enterprise. And while that is a tangible goal, you can only do it some at a time.

This left me with the final question... If I shouldn't be the one driving my work, then who should?

A User-Centric Approach

One of my favorite parts of Airtable's brand identity is the democratization of software. As a tenet, it represents a paradigm shift away from the days of needing to hire a full-time systems architect, administrators, data engineers, etc., to get you the types of tools and business functionality that Airtable enables you to do off the shelf. We can create clean, sleek, powerful, and affordable(?) solutions. (Airtable, you're not off the hook. We need to have a serious discussion about your self-service pricing model.)

If you asked me to pick a single word to describe Airtable, I would respond: "You!"

Your data, what's important to you, how you work, and who you work with define what a solution for you looks like in Airtable. I love watching people at events, videos, or articles try to answer questions about what Airtable is.

The answer that matters comes with context.

• Are you a small business owner that manages inventory, sales, and customers?
  Airtable is many things, but for you? It's a CRM!
• Are you the manager of a marketing team? Airtable is an asset and content calendar tool!
• Are you a recent graduate struggling to track all your graduate school applications? Airtable is a way to keep track of application deadlines, outstanding tasks, and notes on schools you're interested in!

What's The Story?

My appreciation for user context is present in my focus on my first critical idea in thinking of onboarding and building in Airtable: User Stories.
For the uninitiated, user stories are almost thought of as thesis statements that explain a process from the point of view of a specific end user.

The concept largely stems from the agile project management/software development paradigm. Even if you're not working under the agile framework, if you're anyone that works to create deliverables for customers and stakeholders or have a few small-scale projects to complete within your team, you might benefit from writing a selection of user stories.

Here is a user story written down in my dedicated Airtable notebook that I'm working with right now:

As (business owner name), I want to easily manage my inventory and sales to run my business efficiently and make informed decisions about ordering and pricing.

I want to easily add and update my inventory, track my sales, and generate reports showing me which products are selling well and which are not. I would also like to set up automated alerts for when inventory levels reach a certain threshold to know when I need to order more of a particular product. Additionally, Airtable could provide insights into pricing and profitability, such as showing me which products have the highest profit margins or suggesting pricing adjustments based on current market trends. Having all this information easily accessible and organized, I can make informed decisions about my inventory, pricing, and overall business strategy.

This user story tells me that I need to build:

• Tables for Inventory, Sales, Customers, and Products.
• An Interface with summaries, charts, and financial reporting.
• Automations to alert my stakeholders of their current inventory levels.

What Empowers Users?

User stories are relatively easy to write. It's putting them into practice and knowing how to use them to inform your work that brings a bulk of the challenge.
This brings us to the second critical idea that I prioritize when building and onboarding in Airtable: collaborate with your stakeholders.
Keep your stakeholders informed during each step of the build process. Schedule check-ins, write updates, explain the user stories as you understand them, and make sure everyone is aligned on what's important.
Don't get caught up in asking stakeholders to name each field they want, the formatting, the automations, etc. The answer to the question of what you need to build will be revealed by understanding the user story.

If you held me to the fire and asked me what Airtable is without the context of a user story, I would tell you that Airtable is collaborative database platform. The key idea there is collaboration.
As a builder, developer, user champion, or even a single person using Airtable for a small personal project, building a workflow or new base in Airtable is also a collaborative process with your users.

This is true even if you're building something for yourself.
Know why you're building. Look at what you're building. How does it facilitate, support, and scale the workflows in your user stories?
If I realize that I have to onboard a team into a new base or workflow, I haven't succeeded in crafting something that tells their user stories. More importantly, it means that I have neglected to keep them involved in the process of building and that what I'm bringing to them is foreign and just doesn't click.

In the past, when I've made the mistake of building by myself in an uninformed way and tried onboarding and training users, I heard this a lot:
"I think I just need to learn Airtable and get better with it."
The tool is not the problem in an overwhelming majority of these instances. That sentence means that I've failed to fully understand the requirements, and I've lost sight of the user story.