An Intake Form for Data Requests
A couple of weeks ago, I posted a question from our data team's intake form on Twitter:
... which kicked off a conversation around intake forms more generally. I got many requests to share more about our data team's intake form and I'm happy to do that in this post. If you want to skip ahead, you can check out a sample form here.
In the beginning, there was no form
Our data team formed in January and consists of three people -- a data scientist (me) , a data engineer, and an analyst. We soon started getting data requests from all over the company, which would come to us, individually, via Slack channels, emails, meetings, and good ol' fashioned desk drop-bys (remember those?).
Some of these requests were truly painless; they came to us fully-formed and were easy to knock out. Others needed follow-up, with clarifications coming at the (varying) speed of circle-back DMs, and required legwork just to nail down the ask or define the scope. To say that we were doing lots of context-switching would be an understatement. We realized that a more uniform, automated way of gathering requests would help us to better track and triage them, and decided to create a centralized intake form.
We modeled our new intake process after our design team's, who had done a great job of creating and introducing request forms to our company. Following their lead, we posted links to the intake form in our Confluence space and our "public" Slack channel, and made filling form submission the first step to getting a request on our radar. Once submitted, the forms come to my inbox (as the team's lead and manager), and I figure out next steps (further conversations, kickoff meetings, tickets, prioritization, etc.).
Questions we ask and why
Our intake form is opinionated. Years of designing and carrying out analyses has taught me that the more context I have up-front, the better my analysis will be. So, our intake form is designed to gather as much context as we can reasonably get in a few questions.
You can check out a sample intake form here, but I want to call out a two of my favorite pre-analysis questions and why I recommend asking them:
What decision will you make or action will you take with this data?
When I'm framing an analysis, it's helpful to know how the deliverables I provide will be used before I start working on them. The planned decision or action heavily informs the design of an analysis or test from start to finish.
This question also underscores that work requested from our team should result in action. (Nobody wants to spend time creating something that goes unused, or pull numbers for numbers' sake.)What is the real problem you're trying to solve?
There is often a gap between the request as stated on a form and the larger problem it's trying to solve. As the data subject matter expert, understanding the why behind a request gives me an opportunity to add value by working with the requester to fill any gaps. Most often this means recalibrating the analysis based on a combination of the data available (and its quality), the 'real' question we're trying to answer, and any work on similar problems that is in-progress or already complete.
A good rule of thumb is that if you find yourself asking the same analysis-framing question 3 times, it's a good candidate for your intake form.
A little friction goes a long way
One thing we were mindful of while creating an intake form is that we were adding friction to the data request process. Doing so purposefully and in small doses has made our intake process much smoother, and has reduced the amount of work needed to collect pertinent information for data requests. An ideal balance is just enough friction to filter out lazy asks, but not so much that you discourage folks from bringing their requests to you.
We've structured the form in a way that tries not to add too much overhead to simple requests. If you walk through it, you'll notice the form has some basic control flow logic based on request type; so for example, we make it very easy to report a bug by asking only two questions ("what needs to be fixed?" and "is this a blocker?").
Our intake form isn't a substitute for conversation; it's the foundation for it. Adding this step before a kickoff conversation provides us with extremely useful information and gives us context and time to digest and prepare, making our conversations more informed and more productive. Put another way: the answers provided on the form aren't taken as gospel; they help to understand the ask, and give us a better foundation for further conversation.
Further iteration
I've loved reading through the conversation started by my tweet, and it's already given me lots of ideas for iterating on our form. In that spirit, I wanted to share a couple of intake questions I found interesting:
Who will see this deliverable?
Knowing your audience is key for creating an appropriate deliverable! A data person may be okay with a metric labeled median_days_conversion, but that metric would probably need more context to land in a board room.
Above said, I can't tell you the number of times I've created a deliverable for one team and received questions or feedback from another. Unless the thing lives on my computer, I assume it will be shared, but asking with who specifically is intriguing.Will this deliver business value within 90 days?
This straight 🔥 is brought to you by GitLab's visualization / dashboard request template, and reminds me of a question we used at a previous company, basically "Which OKR will this move?" (with a link to the company-wide OKRs).
Asking these kinds of questions outright both reduces lazy asks and ensures that your work will deliver meaningful value to your organization; both are wins in my book.
If you're considering creating your own form, I can't recommend templating, in general, enough. Before this form, I worked on a couple of similar ideas (a ticket template and hypothesis / analysis outline docs), and many of the questions on our form came from these past experiences -- all of which improved data team workflow. I hope our intake form template is helpful as a jumping off point for anyone who wants to create something similar in their company.
If you've created something similar for your company, or have questions about our form, I'd love to chat more on Twitter or in the comments here. If you'd like to get new posts delivered to your inbox, please subscribe via the link below. Thanks for reading!