CROWeekly: Reducing Project Data Bloat
What Happened at Corvus CRO Last Week
How Corvus CRO Manages Split Tests Efficiently
We use a Kanban board view in Airtable to monitor and manage experiments. Each experiment is an Airtable record, which translates to a card on the board. There are 5 channels for progress stages of an experiment life cycle:
- Idea – a new potential expriment submitted via a hypothesis builder
- Plan – calculate the experiment’s sample size, run time, and priority in the testing plan
- Build – set up the experiment in the split testing platform
- QC – review the experiment and approve it to go live
- Active – the experiment is live
- Complete – the experiment has concluded
Moving a card from one channel to another triggers automation for repeatable tasks like sending status notifications, running a report, or updating project information. We use Basecamp for project management, but this process can be applied to almost any project management platform that has API, like Asana, Jira, or Trello. The automation is set up to use API hooks for performing simple, repeatable, standardized processes like creating projects/tasks, adding notes, and assigning tasks. This significantly cuts down on overhead and eliminates a lot of tedious manual configuration drudgery from the project management process.
Updating Our Process to Reduce Data Bloat
The goal of any good project management process is to minimize overhead. One important component of project management is dealing with data bloat. A lot of project data has a shelf life; it’s relevant and useful for only specific period of time. Data bloat accumulates when tasks aren’t acted upon and data goes stale. As data piles up, it becomes harder and harder for users of the system to find relevant information quickly and actually get work done. This wastes time and causes frustration. Worse, information bloat can lower morale if ignored for too long. To help combat data bloat, we’re making a change to our project creation automation.
Previously, we had the automation set to create a new project for an experiment when it was moved into the Planning stage. A lot of projects were getting created. Projects for lower priority experiment ideas were just sitting open and unused, making it harder to find the active projects. Sometimes an experiment idea would be scrapped or modified before it was ready to build. If a project had already been opened for that experiment then it had to be manually updated, creating unnecessary revision work.
Now the automation creates projects when an experiment idea progresses to the Build stage. Building an experiment is where the bulk of actionable tasks begin, so this change should help increase project data freshness. Projects will be created more closely to their “ready for work” state instead of sitting open and unattended. The tasks that go on during the planning stage have been migrated to a separate, repeatable weekly task.