Clarity Forces Solutions
I promise I’ll shift gears away from this whole “clarity” thing, but it keeps paying dividends so I keep writing about it. Like what you read? Hit reply or the thumbs up button.
Hahahaha. In our weekly sync with engineering to go over bugs that are impacting customers, one of our engineers shared that he was going to fix one of the bugs on our list. Which, that in itself wouldn’t be noteworthy—fixing bugs is what they do. What was so funny was that this was supposed to be one of the bugs that they weren’t going to fix.
If communication forces clarity, I guess clarity forces solutions (sometimes). You may recall from a couple of weeks ago how I shared that for some hard-to-fix bugs, we want to improve how we communicate:
You’re not going to say you’re going to fix the bug (remember, it’s not a priority right now), but you want to ratchet forward the level of clarity you’re able to deliver.
For the issue in question, all we were trying to do was improve how we communicate about it to customers, but in the process, we realized it wasn’t as hard to fix as we originally thought, so now we’re going to fix it.
Oops.
Photo by Egor Myznik on Unsplash
Few problems can survive their thorough description
One of the efforts we’ve teed up over the past month with engineering is going through a small backlog of customer-impacting issues and doing the “start writing” efforts that I described in my previous newsletter. The process is pretty straightforward. We’ll create a new card in our bug tracker and add several sections to be filled in by a support engineer and product engineer over a call (it could be done async—calls work for us right now).
What are customer’s reporting?
Why does this problem exist?
What would it take to fix the problem?
What can we say to customers?
What’s the customer impact?
The “What can we say to customers?” section is the crux of the entire process. In fact, it’s the entire reason we’re on a call together. Engineering said this problem was hard and so we can’t fix it right now. Customers said it was causing a lot of pain. So we’re stuck in the middle, needing to communicate to them.
The problem (problem?) is that if you start clearly describing the problem—by literally writing it down—you might just find that the solution is much closer than you think.
This shouldn’t come a surprise at FullStory (disclosure: I work at FullStory), where clarity is one of our watchwords, which we sometimes sum up with the aphorism, “few problems can survive their thorough description”. As Bruce Johnson, one of FullStory’s cofounders, writes:
The very act of describing a problem can often reveal its solution. For example, FullStory engineers make a habit of “talking to the fern”—the fern, as it were, is another engineer who mostly listens, smiles, and nods—to explain the symptoms of a tricky bug in excruciating detail. By the time they’ve finished fully putting the problem into words, the cause of the bug becomes obvious.
Even if it shouldn’t come as a surprise that we found a way to fix a bug, I still thought it was funny. We weren’t trying to force anyone to fix a bug! We just wanted to do a better job communicating and a bug fix was the result. Whoops. I guess we’ll have to try to do a better job communicating with our customers more often.
Etc.
Things I’ve read:
I’m still on a Hamilton kick, so much so that I started reading Chernow’s Alexander Hamilton biography. I’ll have to report back when I’m done, but so far so good.
I enjoyed this vignette from the folks at Jumbo about their product analytics journey. Yes, it gives some praise to FullStory, but what really interests me is their journey to refocus and find measurements that actually matter.
And of course Matt Levine’s newsletter. See the section, “If you buy stock in a bankrupt company because you don’t know how bankruptcy works, should the rules of bankruptcy be changed to allow you to get your money back?”