Turning daily improvements into milestones
Turning daily improvements into milestones
Improvements compound. Even if you don't improve every day, improving more than 1x/week has big returns. Read: Everything Starts Out Looking Like a Toy" #169
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. This blog starte with What is Data Operations?
This week’s toy: a sampling of imaginary candy for your Halloween as dreamed up by AI. Six months ago, these images were not nearly as detailed. By next Halloween, they might be realistic enough to inspire new candy flavors. Edition 169 of this newsletter is here - it’s October 30, 2023.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ Turning daily improvements into milestones
You’ve seen the statistic. 1% improvements daily for a year yield a 37x return.
But it’s 365 days in a row, you say. How can I get better every day?
Even if you only manage a weekly improvement, that’s a 67% improvement.
The process of finding, improving, and adding that knowledge to your toolkit is a valuable, iterative process. How do you build a cadence of observing, experimenting, learning, and documenting?
The OODA loop teaches you to observe, orient, decide, and act.
Using this framework is a solid way to find improvements, particularly when you make mistakes.
Mistakes = Learning
Instead of looking for daily improvements, why not look for the next time you make a mistake? Mistakes will happen if you are trying new things and stretching yourself. So change how you think about them!
Use mistakes as an opportunity to learn something.
Recently I got feedback that I was sharing too many topics in a single communication. Because it was overloading the communication, it was hard to get an answer to the specific question I’d asked.
The request? Simplify the ask for quick understanding. Any ask requires context switching. If the switch doesn’t allow for an answer (or a realization that there is a need for a longer meeting) that’s a waste of a context switch.
Why was this happening? My brain works fast, especially when I’m in the middle of a problem. When I share information, it might not be in the right order or organized enough to understand. The “v1” that comes out of my head needs editing.
The answer wasn’t coming out clearly enough. I needed a template to share communication - mostly to remind myself of the critical factors other people needed to get context.
When you learn something, write it down.
Think of this as the standard operating procedure for asking and answering questions. It might feel mechanical but is crucial to writing this new procedure to memory. I learned some key things to clarify the way I was communicating and needed to write a template for myself as a reminder.
The template I’m now using includes:
BLUF - a bottom line up front statement about the topic
Description - a few bullet points of detail to give additional context
Proposed Business Goals - the “why” we need to pay attention, to and what we’re planning to do
How this will work - the mechanical steps of the process in order
Open Questions - any unresolved issues that we find
I’ve tried this procedure 5-10 times now and have found a few key benefits.
Writing calms my brain when I am not sure what to share first.
Using the template lets me “fill in the blank”
The end product is more consistent and provides a record for later review
Think of this process as programming the human ;)
When you write it down, teach someone
Does this process work? I think it’s a work in progress. I’m writing it out to teach it to you. When you teach someone, it builds on things you already know to create new understanding.
For example, writing this essay made me realize that I could use this context to prompt ChatGPT to share a summary of the chat at the end of a question I ask it (do this by adding custom instructions).
What’s the takeaway? Mistakes are inevitable. They are a valuable opportunity to use the OODA process to learn why a challenge happened, what you can do about it, and how to remediate the issue. The goal? Get a little better every time you fix a mistake.
Links for Reading and Sharing
These are links that caught my 👀
1/ Keep it simple - cognitive load is real.
It’s tempting to build a complete product or idea when you start. If you keep things simple and atomic, it’s a lot easier to get feedback on the specific area that’s working or going wrong. Complicated systems = complicated feedback.
2/ IFYKYK - Matt Webb writes a fascinating story about hyperlocal FM radio in Japan in the 1980s. The ability to share customized low-power radio sounds like a prototype of social media or streaming playlists, where tastemakers share songs for those in the know.
3/ Structure creates structure - Team Topologies is a book by Matthew Skelton and Manuel Pais on the impact of Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
What does this mean? If you want cross-functional team communication, you need an organization that values cross-functional interaction. Sounds simple when you say it that way ;)
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon