Did a presentation at work today about editing PDFs with Python. Mixing and matching libraries is fast, but you’ll run into a bunch of inefficiencies that result in slow processing and huge files. I should write a book. For serious.

Checked in at COPEN LOCAL BASE KAMAKURA. Burritos!

Checked in at Tsurugaoka Hachimangu (鶴岡八幡宮)

Reflecting back on the products I've released over the years I noticed a key difference between the successful products and the non-successful products. The difference wasn't in market or craftsmanship. The difference started before I wrote a single line of code.

With [ImageXY ](/past-projects/imagexy) we were focused on designing a solution to real estate agents uploading photos that were the wrong size or too large into a crm. When building it we concentrated on that single use-case and kept our solution focused. The result was a batch image resizing app that didn't have all the complexities of its competitors. And it turned out a lot of non-real estate agents _also_ had the same problem and our solution worked for them as well.

Other products, like [Byoyomi](/past-projects/byoyomi), a timer application that let you save and run multiple timers on your Mac, were flops. The application was stable and worked as advertised, but it was more of a solution in search of a problem.

As developers its easy to dive straight into writing code or designing interfaces the moment we have an idea that we think might work. And as a developer taking those random ideas and turning them into a reality is _fun_. But the chances of those inspiration-turned-hacking sessions turning into a successful product are slim.

Instead of diving into code the moment we have an idea, it's critical that you do the hard work before your hacking sessions. The work that isn't necessarily fun and _feels_ like work. Take a step-back form Sketch and define, with words, the problem you're trying to solve.

If you can't clearly articulate the problem and who's having that problem, any solution you build will be equally muddled.

> When designing anything, you first need to define the problem that you're trying to solve.

The major difference between my successful products and those that were just that. The successful products had a clear problem that they were solving for a specific niche while the unsuccessful ones did not. It's much easier to solve for X when you've looked at the rest of the equation.

Listening to the Rework Podcast and @mijustin’s idea of wanting to build calm technology company with @transistorFM completely resonates with me. His interview starts halfway-ish through.[overcast.fm](https://overcast.fm/+Jpthc-lmk)

Fascinating opening statement about the two opposed channels in Ukraine.

> [www.nytimes.com/interacti...](https://www.nytimes.com/interactive/2019/10/22/us/politics/william-taylor-ukraine-testimony.html?smid=nytcore-ios-share)

Went for a walk this morning at the Nakata Interactive Forest. No mosquitoes!