Build rules before applications
Discover more from Data Operations
Build rules before applications
"Everything Starts Out Looking Like a Toy" (#73)
Welcome to the first 72 Find Data Ops 📊 members who have joined us since launch!
Join smart, curious folks by subscribing here:
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 blast from the past: the return of something that looks a lot like Hypercard. Who’d have thought that Apple built things in the 1980s that would be very similar to the component-driven app editing of today? They were clearly way ahead of their time. Watch what they’re doing today if you want to imagine the future. Edition No. 73 of this newsletter is here - it’s December 20, 2021.
The Big Idea
A short long-form essay about data things
⚙️ Build Rules Before Applications
Go ahead. Search in Google right now, something like “How do I <do a popular business process> in <prominent CRM system>. There’s a lot to find about how to build whatever you want in that CRM system (you know the name), and not very much on how to solve the underlying process so that you can implement it in almost any system.
Except that your job as a Sales Operations (or Revenue Operations, or Marketing Operations, or Customer Operations) is not to be an expert at any one system. It’s to be an expert in solving problems. Learning how to use and configure the system(s) you need to solve business problems is table stakes for your real role: being a trusted partner to the business.
What does that mean, exactly? It means understanding the unit costs of the business, the input metrics and output metrics that people care about, and then organizing your daily efforts into a thesis that helps other people know what you care about and why. You will be more valuable to yourself and to your business when you think more about the business process than how to implement it in any one system. The latter is necessary but not sufficient.
Your Co-workers are Not 🧠 Mind Readers
You’ve probably had this thought before. “Why doesn’t my team support me? I’m working so hard to get things done and I’ve made great progress. If they only knew everything that I was doing, surely they would be impressed.” Think along with me for a moment. If you haven’t told your teammates what you’re doing, and you haven’t written it down, and you haven’t spent much time with them in person, the chances that they know what you think are near zero.
Dr. John Gottman, in The Seven Principles for Making Marriage Work, found in long-term committed relationships, approximately 69% of the problems in a relationship are unsolvable. That doesn’t mean there will always be negative emotion in every interaction, but what it does signify is that is very hard to be truly understood in relationships. If you only agree with your spouse or partner about 1/3 of the time, it’s pretty clear you need to overcommunicate with your work team. Time to get to work.
Building Better Rules
With this disconnect in mind, how do you build a series of rules to define your business logic so that when you purchase <prominent CRM system>, you adapt your preferred business rules to that system instead of the other way around?
To paraphrase Stephen Covey, “start with the end in mind.”
For the project at hand:
What is the list of things to be done?
How are you going to know that someone (or some process) is doing them?
What will tell you that a thing is done?
A set of rules is a mental model for how you are approaching a task, what your goals are, and when you will complete it. Your co-workers don’t know how you are going to solve the problem, what problem you’re solving, and how you’re going to do it. So write it down.
A 30 minute Hack for Better Rules
Required tools
An Egg Timer ⏲ (“Hey Siri, create a 30 minute timer” works too)
An open Google Docs document (if you prefer, pen and paper is fine)
Sitting in one place and writing what you think other people need to know (this one is the hardest, and I guarantee you will feel better after you do this)
PROCEDURE:
Write one or two paragraphs on the project. What is the simplest, most jargon-free way to describe what needs to be done? Next, explain the stages of the project as a numbered list of tasks. This is what needs to happen in order. Once you know what’s going to happen, and a rough order of tasks, it’s easier to answer the more challenging parts of this brief.
What could possibly go wrong? This might take the form of asking the open questions that haven’t been answered yet. It might be whatever is in your head that you are worried about and haven’t solved. Write it down so that other people will see what you are thinking.
Finally, make sure to point out a general timeline with resources, indicating if you think you are stuck or where you need help. After you’ve done this, take an editing pass and remove some words so this is easier to read.
Your Co-workers are Not have become 🧠 Mind Readers
Amazing. With the simple step of recording your thoughts on what the project is, what needs to be done, and how you’re planning to approach it, you’ve made your team into a bunch of mind readers. Well, not yet. What you’ve done is made it easy for them to have a discussion with you on how you are approaching the rules and where they agree and disagree.
Now, you’re ready to implement your business process in that well-known CRM (or any other operations system). Stating your inputs, the desired outputs, and the philosophy of how you want to get there makes it much more likely that you will retain your original business design even if that SaaS considers the problem differently than your idea. Is it perfect? Nope. But it does solve the initial problem that no one knows what you are thinking.
What’s the takeaway? Writing a simple process moves the discussion around a project from “no one knows what I’m thinking” to “let’s have a discussion about *some problem* - here’s what I’m thinking - when’s good to chat?” Stating the assumptions also makes it easier for team members to get oriented quickly and to share relevant feedback in a low-emotion format.
A Thread from This Week
A Twitter thread to dive into a topic
From one of the chief researchers of COVID19 at Fred Hutchison in Seattle, here’s a thread from @trvrb on what might happen with the latest COVID variant:
Links for Reading and Sharing
These are links that caught my 👀
1/ 🥳👍👀 - Which were the most-used smileys in 2021? If you break down the category, it looks like this:
Jennifer Daniel helpfully shares the data on the most used emoji reactions in 2021. Smileys are far and away the most used of all emoji, and it hasn’t changed that much since 2019.
2/ Digital goods people might want - A constant in software has often been: build the digital version of what people want and do already. Linda Zhang has some excellent suggestions on how to create digital scarcity for concertgoers. Collectibles, Zhang argues, are a way to reinforce the value of in-person experiences and are more “sticky” than the value offered by NFTs or digital collectibles with no real-world counterpart.
3/ Remove friction from products - what if you could make authoring a website as easy as writing some notes on a piece of paper. The Paper Website project is exactly about that effort: how to digitize notes and make into digital documents.
Most good products start with a silly idea. It’s neat to think about making web documentation a lot easier and starting with handwriting.
On the Reading/Watching List
Some things to watch or read, in no particular order
Watching: A game demo from the team that built the Matrix Awakens. I’m not an avid gamer these days, and what’s interesting to me is the fidelity of what can be done in a real-time game demo. This is not quite game play, but is a clear roadmap to something that is not real-time and also doesn’t look like any games we’ve ever seen before (except for the heads-up display to tell your brain where to focus).
Reading: What’s next for books, particularly in non-fiction writing? Andy Matuschek makes the case that we need to update the “Book” and to rethink it. Books, Matuschek argues, don’t do a good enough job of catching and keeping the reader’s attention. Because you don’t learn by reading alone, if the goal of reading is to produce learning that you apply, books don’t do it without some help. What if the actual solution is books plus some other reinforcement (e.g. a book group of sorts, and sourced by people who are in your domain area) there are interesting possibilities for multi-player learning.
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