This post originally appeared in my newsletter, Borrowed, Learned, & Thought. BL&T is sent weekly on Mondays. In every edition, I share lessons learned in agency leadership, life, and e-commerce. This post does not include all the details shared in the newsletter sent via email. Subscribe here.
"Presenting is a tool of swaying, while conversing is a tool of weighing. Through the former we try to convince people to hire us. Through the latter we try to determine if both parties would be well served by working together."
From "The Win Without Pitching Manifesto" by Blair Enns [Book]
It was fun to do an NYC day trip last Thursday for the Barrel partner Q1 and annual planning meeting. We use these meetings to reflect and chart territory for the next quarter and year.
A few years ago, we started including a book as a part of our preparation work. Thanks to our fearless leader, Peter, Barrel CEO, for curating the selections. This quarter, we doubled down and read two books: "The Joy of Selling" by Steve Chandler and "The Cold Start Problem" by Andrew Chen. Both books made for a great discussion, not to mention they generated a lot of new ideas for how to think about our leadership and the business.
To close out the meeting, we defined our focus areas for Q1. Then, we celebrated the day's progress with dinner and drinks. It was a blast to see Peter, Sei-Wook, and Wes in person again. I'm pumped for what's in the pipeline and to see the results we create together this quarter.
Peter shared this quote with me last week from The Boutique by Greg Alexander:
"Over time, SBI’s offerings expanded dramatically. When I left, the firm had more than one hundred service offerings. We launched about ten per year. Eventually, we packaged them into a trademarked offering called the Revenue Growth Methodology. The price I got for the firm was 30 percent above comparable firms. And this was in part due to the robustness of the offering. If we did not develop new offerings, I would be running a little lifestyle business right now. To scale, you need to bring new service offerings to market."
These days, Peter and I spend much of our time talking about Barrel's services — where we can expand and evolve. With that in mind, this quote is inspiring and underscores the value of constant innovation. It got me thinking — what does it mean to launch a service? What does a service entail?
Author Seth Godin often refers to the need for a spec when asked about achieving perfection. Having a spec helps him know when to hit the publish button, or put simply — when to let go. According to Seth, "[A spec] helps to define what good enough is before you begin. Because once you have a spec, you can ship your work with pride." (Medium)
When it comes to developing new services, we don't have a spec. Sometimes, we ship ideas with a pre-defined process. Other times, the service lives in a proposal, and we rely on the team to get it done. If we want to ship 10+ services this year, a spec might be helpful, something to guide our thinking and let us know when to let go and put it out into the world.
In our one-on-one last Friday, I shared this with Peter and we briefly explored the details of a service spec. We don't have anything in place yet, but I'm looking forward to continuing this conversation and seeing its impact on how we develop and ship new services.
During High School, I learned a hard lesson about presenting my work when completing my graduation project. If you're curious, I established a school Veterans Day assembly where veterans came in to share their experiences and help honor the day. Graduation projects had three components: the work itself, a written essay, and a final presentation to a panel of teachers. Given the stakes, I was nervous about presenting. Afraid I might stumble, I printed my essay out and cut it down to fit on index cards.
Sure enough, when I went to present, I froze up and started reading from my cards. Within minutes, it was clear the teachers had caught on. One of them held up a stapled 8.5 x 11" paper while moving their finger from left to right and back again. It was like I was doing karaoke, minus the fun part.
The teacher stopped me as I floundered and pointed out what was happening. I apologized and did my best to finish. In the end, I was lucky it didn't impact my grade too much, but the embarrassment made a lasting impression.
I recalled this story last week when I joined a new business presentation call. We recently started experimenting with Notion to format proposals (rather than Pitch). As convenient as these proposals are, I'm not sure Notion is the best tool for presenting our approach.
There are a few challenges with sharing a document via Zoom. As an attendee, it's overwhelming to look at a screen full of words. Then, you start reading them and miss what the presenter is saying. As the presenter, you have to fight the urge to read what's on-screen since everything you want to say is there.
I sensed this struggle in the presentation last week. The team went from reading the screen to talking around what was there. It was hard to tell if the prospective client was engaged. Suddenly, I was back in High School, but this time, on the teacher panel. I thought — if you're going to read what's right in front of me, why are we here?
I jumped in to add my perspective and get the client's input. The rest of the meeting felt more organic, but I shared some feedback with the internal team anyway.
I'm not ruling out Notion proposals, but perhaps we don't share them on-screen and instead use them to guide our conversation. This approach might also make the conversation feel less like a pitch and invite a more personal connection. We'll see. Either way, I'm eager to work with the team on our next iteration and continue experimentation.
In early 2019, we invited Agency Agile to our team to train us on their framework. One of the key takeaways was an approach for project kickoffs called context briefings. The focus of these briefings was to unpack as many details as we could about the client's brand and business. Using index cards on the whiteboard, we'd spend 2+ hours walking through everything learned about the client up until that point, asking them to fill in any gaps.
When we went remote, we ran these meetings using Mural. While it worked well, the time commitment was challenging, especially when the hot topic among knowledge workers was too many meetings. We also noticed project details slipping through the cracks, despite the hours spent with the client. We worked with the team to rethink our process to be more efficient and align on project scope. Since then, the format has been ever-changing.
Last week, I attended my first client kickoff in some time. I had a chance to review the deck ahead of the meeting. I was surprised to see no time allocated for client background; instead, we jumped right into website features and functionality. I thought to myself, is this what every kickoff is like now?
I brainstormed some guiding questions with the Account Director, and a few hours later, we went for it. Sure enough, a key client stakeholder spent almost 40 minutes answering these questions, sharing countless golden details. We took the last 20 minutes to address outstanding questions on features and asked the client to review the rest of the details offline.
The Account Director and I debriefed after the meeting. We agreed that missing those upfront questions would have been a huge miss. At the end of the day, though, I'm glad it happened. We haven't followed up after setting the team on a new path last year. They've made good progress on project alignment, but along the way, have lost sight of what was working with context briefings. It's time for a new iteration.
So, what makes a great project kickoff? My gut tells me that those details will change over time, but I know one thing for sure, a great project kickoff always includes space for the client to tell their story and inspire the team. Sometimes, the project kickoff is the only time the team will have access to stakeholders like the CEO or founder; it's critical to make good use of their time and learn as much from them as possible.
In what areas of my work could a spec help me keep momentum, commit, and deliver?