Three Ways to Create Agency Case Studies on a Shoestring Budget
January, 2024
January, 2024
2-min read
Summary: If you are an agency without a dedicated marketing team or budget, make it part of your project delivery process to capture case study and thought leadership marketing content. Read about a few strategies I tried – some that actually worked! – to bake the content capture into our project team’s processes.
Although my title at Mutations Limited, a 20-person boutique software development agency, was Managing Director of Strategy and Services, I did a little bit of everything. In 2022, we decided to focus on developing case studies and thought leadership articles that would live on our website and support SEO and sales. But we didn’t have dedicated Sales, Marketing, or Communications people and we had never put much time into that aspect of the business. In my do-lots-of-things role, I chose to drive the content strategy and development.
The first few case studies were a snap. We had at least half a dozen stories of clients who LOVED our work – including some major brands you’ve definitely heard of. I interviewed the devs, re-read notes and client reports, and asked the clients for testimonials. I contracted a professional marketer to draft up a case study and template for one case, with the goal of using that model for additional ones.
"We wanted to capture the heart and soul of a project, and its value to our client, while it was fresh."
Although these early cases were straightforward to write, I noticed that the client and team struggled to remember the details worth sharing – even for projects completed just a few months earlier.
What are two critical elements to those details? Let’s agree –
Capturing how it FEELS to work together on the project. Our client-facing process was transparent, and clients had a uniquely high level of trust towards us. But those feelings were not top of mind when we discussed the project after the fact.
The innovative way we approached the project and the problem. Our team would frequently pivot with clients’ changing goals, acting as though we were employed at the client business. This was a key part of our competitive advantage, since most agencies don’t operate this way. And yet our own team easily forgot the nuance of our iterative process once the solution launched.
So our Exec Director and I thought about how we might create a branding content development process; a flywheel of sorts that would allow for continuous raw content development as projects were happening, rather than afterwards. We wanted to capture the heart and soul of a project, and its value to our client, while it was fresh.
In the iterative, continuous improvement model I love so much – and with little to no real marketing budget to work with – I tried small experiments one by one to see what would work.
Out of five strategies we tried, one worked remarkably well:
Training every project team to ask the right questions about value-addition and innovation at Team Retrospectives
I built regular Retrospectives (including with the Client present, when appropriate) into the standard project operating procedure. As a project team we’d look back at what could have been better and look forward on how to apply lessons to other clients and projects. We’d always have a Retro after projects finished, but also scheduled them mid-project, post-launch, or at regular intervals.
I attended all the Retros and asked the team what about the project might be something we could share in a case study.
5 out of 5 - Huzzah!
By dedicating 90 minutes to each Retro, we were able to brainstorm together and give the devs a chance to think deeply about what was special and unique about our work. And because clients sometimes attended, we could simultaneously advertise our team’s critical thinking skills while gathering client feedback at the same time! No time like a Retro to get a solid client testimonial, too.
The key to this strategy was the freshness of memory – innovative steps and processes were still top of mind for the team.
My takeaways from the strategy that worked:
Document nuance, wins and process close in time to the actual work happening.
Ritualize capturing this content by scheduling regular project Retrospectives that are explicitly designed for meta-level process analysis. Leave enough time to allow for thoughtful brainstorming.
We tried several other strategies, first. The first two below had legs and could have worked better with some tweaks. The other two failed, but still taught me interesting lessons:
Asking teams to present what’s cool that they’re doing at an all-hands — and take notes!
Our team all-hands every 6-8 weeks always featured a project showcase by one of the project teams. It was a great place to learn about some on-brand, innovative work the teams were doing. I started asking the teams at their showcase to share what else they thought was marketable about the process and the work.
3 out of 5– Not bad.
As a concept this was great. The meetings were just not frequent enough and the showcases weren’t detailed enough to support the deep dives I sought. But this strategy did get the team thinking about marketing our services as something they could contribute to.
How could it have been better?
This could improve with more time and frequency. It gave me the idea to harness the team retrospectives and add to their agenda.
Running a 5-minute round-robin at the weekly PM meetings to mine for case study ideas
At my weekly with my project team, I would ask every week if anyone had any work that was worth diving into for case studies or thought leadership articles. Had any interesting conversations, coding processes, solutions, or wins for the client popped up since the last week that we could write about?
2 out of 5 – Meh.
This didn’t yield much fruit. My PMs were oriented towards success for clients, not towards our own brand. That’s not necessarily a bad thing. Having the conversation weekly helped train their brains to think about both and see the client work through another lens.
How could it have been better?
Project leads are usually some of the best people to see the top-level value a project is bringing to a client, so this has potential. This could have worked better with a longer meeting where we focused on marketing / sales rather than our usual tactical themes.
My failed strategies taught me just as much as the one that worked.
Photo credit to Kind and Curious on Unsplash
Paying engineers to write content
We had some articulate engineers on our team who were doing innovative dev work. So I got our leadership team to agree to pay devs $500/article for writing up semi-publishable thought leadership articles on interesting work they were delivering for a client (omitting proprietary info, of course).
1 out of 5 – Nope.
Ultimately our devs couldn’t find the time to do this writing – and on our team, it really wasn’t part of their practiced skillset. They needed more support.
How could it have been better?
This may have worked with a blog template, more examples, and regular support to ensure the technical team had the help they needed. A content schedule and roadmap that factored in their client work would have helped, too.
Building content capture into the task management tool
In our project management tool, ClickUp, I had my teams add two fields to their task management dashboards:
1) A checkbox labeled “Client Win” and,
2) An open text field.
Anyone on the team (engineers, QA, PMs, even the client) had the opportunity to check that box and write notes describing the “win” on a specific task. E.g. If an engineering task resulted in a great feature that the client found extra valuable, the team could mark it as a Client Win. At the end of the sprint or delivery, I could go back and capture the “why” behind the success.
1 out of 5 – Nope.
Not a single person used this feature in ClickUp. Dev tasks were too granular in most cases to capture a real client win. Plus, it missed meta wins, e.g. a process or way a feature was rolled out rather than a specific feature set.
How could it have been better?
This may have worked at the Epic level rather than the task level. But the truth is that no one was spending any more time in the project management tool than they needed to. It just was not a space for brainstorming.
Summing it up, when tackling a new process with little budget to support it, my top recommendations are:
Try a lot of things. You never know what will stick best with your team.
Don’t expect your devs to own writing about their work. They need support (and maybe even a project manager).
Gather feedback quickly and continuously. Don’t try a mediocre process for long before learning it’s not working. Once you find one that does work (for us, those Retros), build them into your regular processes quickly.
***
Have comments? I'd love to discuss. LinkedIn / Email me at liana at lianaris.com
Banner photo by Patrick Perkins on Unsplash