Finding the right level of detail
"Everything Starts Out Looking Like a Toy" #93
Subscribe now to join smart, curious folks who get the Data Ops 📊 newsletter
Hi, I’m Greg 👋! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, it’s fun.) If you need a background on how we got here, check out What is Data Operations?
This week’s toy: a machine learning model that can learn to classify things on the fly when given input in the form of a question. It’s not too long before you’ll be having simple conversations with a machine to solve typical problems (if you’re using chatbots, this might be happening already). Edition 93 of this newsletter is here - it’s May 16, 2022.
The Big Idea
A short long-form essay about data things
⚙️ Finding the right level of detail
If you’ve spent time explaining technical concepts to a prospect (or perhaps a fellow member of a product or engineering team), you’ve had the experience of getting a completely blank stare as a response to your explanation. Hopefully, this doesn’t happen to you most of the time, and it’s absolutely going to happen to you at some point. The root cause of this look is probably too much detail and not enough context in whatever you’re trying to convey.
The goal: deeply understand the customer
A prospect (or a fellow co-worker) wants to solve a problem. Until they want to know about the specific details they need to solve their problem, giving them that detail is not going to be helpful. You are more likely to get the Homer Simpson blinks above instead of a hearty “thank you” or an engaging conversation.
So what’s the goal when you find yourself wanting to explain fine detail? Stop, orient, and understand the situation. Remember, the goal is not to prove how smart you are.
The goal is to match the solution you’re offering to the benefit the customer (internal or external) is seeking, and find out the best way to make that happen given the constraints you have. (SPOILER: not all problems are solvable right now, and most problems are resolvable given enough time and resources. That doesn’t automatically align the problem you want to solve with your solution.)
To create a good problem-solving environment, arrive with some details (even if you don’t share them all). You’ll need:
Analysis: why have they arrived at the conversation? What is the top-level issue that they are facing?
Alignment: to orient the person and their issue with the problem you’re solving
Solution: there might not be a solution yet. Take the time to work through the analysis and the alignment to get to a full accounting of the problem.
Once you have a better sense of where the conversation could go, your next task is to determine how to get to an agreement. Roughly speaking, you’ll want to restate the problem, identify how it could be approached within the current framework you use, and suggest some potential ways forward.
Getting to “yes” in a problem statement
In the product process, we try to group related problems into a feature or a set of features. A “Product Requirements Document” intends to answer prospect or internal questions by arranging information in this way:
An overview of the problem: what is it, and why do we need to solve it? If you don’t know this, go back to the beginning and ask more questions until you have a solid answer. In a customer or prospect situation, this might take several interviews to resolve. In an internal conversation, it might take alignment on a common metric or outcome.
Terms and definitions: aligning on a common way to describe the things we’re talking about. If we don’t have an agreement on terms, it’s going to be challenging to confirm we’re talking about the same thing.
A concise description of the issues: how does the customer (or the internal customer) perceive the problem? What’s the tangible (or intangible) benefit of solving these issues?
A proposed fix or fixes: if you’re leading with how to solve, you might not know the real problem. Start by hearing about the issues, then test whether the fix addresses those issues
A picture: of course you need pictures. The key one to provide here is a diagram that’s not strictly a diagram. Think of it as a “day in the life” explaining how someone experiences the situation, rather than an engineering diagram. If you’ve ever seen Richard Scarry’s classic illustrations, here is an example:
Confirm the suitability of the fix: the point of a conversation like this is to determine if you’ve identified a problem they care about, and a potential solution that sounds workable. If you hit the mark, you’ll get an invitation to talk in more detail.
How do I make this happen?
Once you know the story, you can tell different versions depending upon the audience. The basic idea is the same and the details are different.
Here’s a (very oversimplified) example of what the prospect expects to see when discussing a process. Some stuff happens, you wait a bit, and then you get the result you expected. They don’t need to know why it’s happening, but to internalize the outcome of what happened. You may add some details to provide a jumping-off point, but it’s likely that you know a lot more about the internals of the problem than they do.
Compare and contrast this example with something a more technical user might want to see. This diagram (about the same thing) could look more like this.
It’s still not an engineering diagram but opens up the discussion to include more parts of the process.
Progressive display to the rescue
This strategy is a form of progressive disclosure, where you reveal more information (and more decisions) as you get deeper into the problem. If you need detail, the prospect (or colleague) will ask you to get very specific. It’s possible (and advisable) to follow this same structure within a story that describes the interactions or states of interactions for each of the small pieces of the feature above.
What’s the big picture? For each different scope, you are effectively selling a different solution. Think of this as a form of enablement where you are customizing the explanation for each layer of the problem.
Building a bridge to the customer (internal or external) is a key part of understanding the problem they are facing. By working with them to identify potential solutions, you remove some of the friction you’d see by adding detail prematurely in the process. That new knowledge makes your validated solution a lot stronger to pursue.
What’s the takeaway? A product requirements document is the outcome of a series of conversations designed to deliver alignment and specificity. If you are having talks with prospects, these might group into a theme of features rather than a single idea. Regardless of the audience, the purpose of the PRD is to deliver the right amount of detail at the right level to answer the questions being asked.
Links for Reading and Sharing
These are links that caught my 👀
1/ Writing diagrams with code - This tool creates pictures to go along with state diagrams when you are describing product or process behavior. It’s cool because it makes it a lot easier to cut and paste a process and edit it quickly. It’s not ready for the casual user, but it’s a quick way to document process.
2/ Common problems with process mapping - Ian James is a process consultant. This video describes some of the most common problems in describing processes, using … process documentation ;)
It helps to remember that behind a great process is a solid and believable story. Walking through the process (and the problem) builds empathy for the problems and how to fix them (once, of course, you’ve mapped them).
3/ A whole lot of flowcharts - If you’d like to read more about charts and the history of flow charts, this is summary by the folks at Zenflowchart is a great start. From defining the individual items in a chart, the overview of which kinds of charts are useful for which purpose, this article is excellent at setting the stage. (Don’t worry, no one’s going to make you learn UML.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon