LIMITED TIME OFFER! I’m ready for my next adventure as a DevRel advocate/Technical Evangelist/IT Talespinner. If that sounds like something you need, drop me a line in email or on LinkedIn.
DISCLAIMER: I do not believe that I’m the universe’s gift to DevRel. I don’t have all the answers, all the experiences, all the skills, or even all the Pokemon. What I do have is my experiences, collected over 11 years of doing this work. That’s what I’m sharing in this series.
Work at a software vendor (or really any group that creates features for a set of consumers – whether those consumers are internal users or external customers) for any length of time and inevitably you experience a moment when a new feature, module, or capability is released to the public, and the response is the human equivalent of this:
It becomes clear that the intended audience has no idea what the new feature is, why it’s there, or – most critically – what problem or use-case it addresses.
This is not (or at least not always) because the feature is badly designed, ill-conceived, or poorly executed. Sometimes, the response from users is because the problem hasn’t been socialized well enough. Nobody understands the nature of the disease, and therefore, they can’t understand the importance of the cure.
As a DevRel, almost as important as our work helping folks understand HOW (to install, to use, to extend) is explaining WHY: Why is this capability necessary? Why did we decide to create this instead of 6 other things on our backlog? Why does this feature provide an optimal way to solve a particular problem?
But I’ll be honest: Explaining HOW is relatively easy. Explaining WHY can be a lot of work.
One of the techniques I use that makes explaining WHY easier is a variation of the Texas Sharpshooter story. While this is normally categorized as a logical fallacy (and, when used in data analysis or debate, it is), for Developer Relations Advocates, it is actually a fairly useful technique.
The Man, the Myth, the Legend
I’ll start with the colorful story behind the evocative name:
Once there was a prince who was also an accomplished marksman, who was traveling through the land. Along the road he stopped at a village to rest his mount. He sat down under a tree—and right there in front of him was the side of a big barn. He couldn’t believe his eyes. That whole side of the barn was covered with little circles, drawn with chalk, and in the center of each circle was a bullet hole! He jumped up in amazement. Who is this sharpshooter around here who never misses? Maybe they could have a little contest while he was here.
So he knocked on the door of the farmhouse and asked if they knew who the marksman was. Yes, they did. They brought him a barefoot boy of about twelve. ‘Here he is, Your Excellency, our son the sharpshooter!’ Of course, the prince was surprised. He asked the boy, ‘Tell me, young fellow, how do you manage to hit the bullseye all the time? Here, look at all these medals. I’ve just finished five years of training and even I couldn’t hit the target every single time.’
‘Oh,’ said the boy, ‘there’s nothing to it. I just like to shoot. So I shoot at the side of the barn and then I take a piece of chalk and draw a circle around the hole.’
Context Matters
Shooting the bullet and then drawing the target later makes for a bad-faith argument, but it turns out it’s perfect for content-planning.
When you work “inside”, meaning you are working with the developers of a product, you are actually existing weeks or even months in the future. What I mean is, your day-to-day thoughts and internal discussions are about a future version: how it will work, the problems it solves, etc. Whereas the users of the product only know about the features and capabilities they have today.
It’s often a challenge to remember that your context – the problem you’ve been working on for weeks, the one that will be solved with this next release – is completely unknown and unexpected by the majority of users. They haven’t been pondering the complexities of the use case. THEY haven’t been investigating ways to remove friction, toil, or error.
Your v-dot-now is their v-dot-next.
The mistake many organizations (and the DevRel’s right along with them) make is releasing the new version with the expectation that everything – the problems, use cases, and purpose of the new version – will be intuitively obvious because, duh, we’ve been talking about it FOREVER, right?
That’s how you get the German Shepherd look when you do the big reveal.
YOU know what the feature is going to do, what problems it will solve, and what improvements it will bring. BUT… you also know it won’t be ready for a little while. Talking about it now, when features could slip, deadlines might be missed, priorities re-arranged… heck, when entire teams could be re-assigned… promoting the solution now would be asking for problems when things don’t go as planned.
But you also can’t talk about nothing. And that’s where the Texas Sharpshooter technique comes in.
The new feature is the metaphorical bullet. It’s already been shot in the sense that development work is already happening. You know where it hit, so to speak. Despite the fact that nobody but your internal team can see it, the landing point is there, on the wall. You’re job right now is to draw a circle around that spot by socializing the problem. You draw attention to the problem, the point where the bullet WILL appear, by drawing a big old bull’s-eye on that spot.
In blogs, opinion pieces, panel conversations, videos, or whatever, your job as a DevRel is to talk up the challenge, cost, and toil of the issue – what it is, why it’s a problem, how much damage it does, and the current (imperfect, complex, kludge-y) solutions that exist.
Period. That’s it. No parting of heavenly clouds, no angelic choir. Just you and the audience bonding over your shared experiences. You give a knowing look that says, “Life in tech, amirite?”
By doing this, you establish the context for the eventual unveiling.
TAMO (Then a Miracle Occurred)
The best part of this technique is that you can have multiple threads like this going at the same time. Because let’s face it, we’re in tech, and we looooove to complain. And show off. And complain about showing off. And show of how we compla…. never mind. You get it.
My point is that the companies where we typically work as DevRel Advocates usually have multiple new features, modules, and improvements in the pipeline at any given time. Maybe only a couple will hit GA soon, but we can get ahead of the curve by socializing those problems and fostering the online discussions, debates, counterpoints, etc., long before the release date.
More than just a clever marketing ploy, the sharpshooter concept also allows the business to understand how customers and the community will ultimately react to the new release. By gauging the audience’s overall understanding of the technologies and techniques, the organization can have improved documentation or educational resources ready to go. By listening to the specifics of the dialogue about the problem itself, adjustments (or even UX/UI sessions) can be added to the timeline.
When used thoughtfully, this technique allows for a better overall product as well as a better overall release.
