what do you take seriously?
a reminder to myself to not overcomplicate things
Hey everyone,
I’m sneaking in 1 hour coding sessions throughout the week to work on Overlay, recording my progress along the way. Twitch has been a little tricky to use, so I’m publishing to YouTube for now. Here are this past week’s sessions:
#2: Setting up basic styling and responsive layout (Twitch fail)
I’m pretty embarrassed by stream #4 above. I pride myself on being a slow and thoughtful problem solver. But recording the process is new to me, and I felt an odd performance pressure to be a beast.
Stream #4 is 90 minutes of me “button mashing”. I overcomplicated something in my attempt to look smart.
I eventually realized that I had my blinders on. So I stepped away from the problem. Went for a walk to the auto shop to pick up our car. Hung around for a bit to chat with the mechanic.
When I came back, it dawned on me that I had abandoned my tried and true problem-solving tools. So in stream #5, I went back to the basics to get the job done. Not the best solution, but good enough to keep moving forward.
Small Tools for Continuous Improvement
In hindsight, it’s obvious. Always think a problem through— keep it simple— etc.
But in the heat of a frustrating moment, I don’t always remember to take a temperature check. This is as true in writing software as it is in playing tennis or building a business or nurturing relationships with loved ones.
Which is why I have two tabs open at all times in Chrome:
Small Tools for Shaping by Ryan Singer
Take a Simple Idea and Take It Seriously by Cedric Chin
Why these two essays? They remind me that I tend to overcomplicate my problems. I try to be too clever.
Not being too clever for a problem gets harder and harder the more knowledge we accumulate. We just expect to steamroll through familiar problems the more sophisticated our skills become.
You know what’s better than clever? Taking a simple idea and seeing how far you can take it.
In this email I’m going to show how I’m trying to do this while working on Overlay.
This is gonna be a case study for Ryan Singer’s simple idea: There’s only a handful of small tools you need to build great products. These tools are not earth-shattering. They are sharp, simple, and effective:
Trace how you currently do things
Flag frustration points
Brainstorm ideas to resolve frustration
Group and label your ideas
Interrelate these groupings
Create a story around these relations
Zoom in and start solving
Zoom out and gather more context
Trace
I’ll start with the genesis point for many potentially good solutions for a problem — watch how the problem is currently being addressed.
This step is simple but hard. It’s easy to skip. I just wanna get to the “solving” part already. So I forget to pay attention and use my eyes and ears.
Observe somebody (or yourself) trying to solve the problem.
Jot down every step they took, from start to finish.
Flag a step that seems frustrating, painful, or convoluted.
For each flagged step, create a dump of ideas of how it could be improved.
Overlay was born the day I ran through this trace process on how I worked on my tennis skills:
The areas flagged in red represent sources of frustration. Reframing them as opportunities gives me a clue that, yes, there might be a better way to do things!
This is how we notice problems in our heads anyways. We’re out in the world doing stuff, something feels annoying, and if we encounter that annoyance enough times, we come up with a workaround for it.
Externalizing this cognitive process out on paper is super powerful. You can compare how you notice problems to how others notice problems. Great starting point for collaboration.
Grouping Concepts
Once I have a dump if raw ideas, I group them. Those that touch similar themes belong together.
Then I label these groups. Labeling tends to tease out the process I’m trying to improve. I’m starting to notice the forest amidst these trees:
This step is also very open to collaboration. I may have grouped these concepts in one way, but someone else might group them entirely differently. They might have completely different labels for the groupings.
If I’m spending enough time observing and listening, these groupings and labels will evolve to fit the problem more snugly.
Interrelate
So far, I’ve grouped and labeled the ways I could improve a process.
Now I have to make sense of these groupings. How do they relate to each other? Does one grouping lead to another? Are there two groupings that are at odds with one another? How do frustrating emotions resolve or exacerbate from one grouping to another?
The output of this exercise is usually a flywheel or a feedback loop. I’m still working through this part with Overlay, so I just created a basic table. But it’s probably more useful to visualize it with circles and arrows.
This step is also open to collaboration. Depending on my personal experience of the problem, I’ll interrelate things differently from another person.
Seeing how others relate concepts shows me what is important to them and what might be a blind spot for me.
A Narrative First Draft
At this point, if I have a strong understanding of the problem, I’ll start tingling with excitement. I’ll want to tell people about it.
A narrative. A way to share information in a memorable way. That’s what I’m gravitating towards.
Some people do in-depth memos, PRDs, pitches, Twitter threads, proofs, papers, etc. They are all very helpful.
But my narrative format of choice is descriptive bullet points. A Table of Contents. If Overlay were a book, what would its table of contents be? Here’s my first stab at it.
This is not good. But it’ll evolve as I continue to have more conversations with people facing the problem.
I’m iterating towards the following… If I share this Table of Contents with the right people, will they be falling out of their seats to try it out themselves? Currently, the answer is No. In a few months, it’ll hopefully be a Hell Yes.
Zoom In, Zoom Out
The next steps from here are ones that I honestly suck at but that successful entrepreneurs are really good at. The daily grind becomes an oscillation between getting in the weeds and looking at the big picture.
To get thisclose to a problem, I can Zoom In.
I’ve seen founders Zoom In by hitting up everyone in their personal network, getting feedback, asking for referrals, finding ways to return the favor, and laying down the foundation for sales, marketing, and product dev.
I’m not a seasoned business fella, so I have a bias towards my current toolkit. My preference is to take 6 weeks to build a first version of Overlay. So to Zoom In on that, I wrote the specifications for how I imagine the product will work.
With the above spec, I can start creating the solution. It could be an app, a prototype/design, a spreadsheet, a conversation, etc.
While I’m doing all this, I’ll also want to Zoom Out and understand what solving this problem will actually do. The big picture.
I’m trying to build a viable business, but I haven’t done this before. So my first guess for what to Zoom Out to is a clear hypothesis of a target customer and value proposition:
With the above value props, I can later Zoom In on finding real customers and assessing their willingness-to-pay for Overlay.
I could have tried to do a lot of the above in my head. But doing things in my head typically leads to sloppy thinking. Plus, I might forget what I worked so hard to figure out.
Having it all in writing gives me something outside of my head to refer to, change, scrap, and share with others.
Conclusion
As I’ve seen in my career working with startups, many struggling founders do not use any of the above tools. They don’t use them for reasons similar to why I lost my cool during stream #4.
When you’re putting your identity on the line to do something, you’re flooded with feelings of inadequacy. Fight or flight responses kick into full gear. Feeling adequate and successful becomes the primary goal, by any means necessary. The ego shields go up; thoughtfulness and vulnerability go out the window.
Some of the problems this creates:
Low-Fidelity Understanding: they keep a distance from the ground floor. They don’t know the nitty gritty details surrounding the customers and their problems.
Conflicting Priorities: one day, they want to chase one opportunity; the next, they want to chase what looks like an entirely different one.
Inflexibility to Change: they don’t view their efforts as bets that could be wrong (or correct but not worth the effort). They over-invest in work that isn’t producing results.
Murky Vision: they aren’t sure why they’re spending all this time and energy on the business. What is this all for? Where should efforts be focused?
These problems are very hard to avoid. We tend to overcomplicate things.
So I’m taking Singer’s small tools very seriously. When I run into trouble, hopefully I’ll know how to get back on track.
That’s all for this week! Thanks for making it this far.
Ammar