A good reminder as someone who tends to jump into the details.

There is a narrative gaining traction in tech circles, on social media, and in breathless conference keynotes that goes something like this: AI will soon let anyone build their own software. Need a budgeting app? Just describe it to an AI and it will create one for you. Want a custom CRM for your small business? A few prompts and you are up and running. Personal software, built on demand, by…

Most people quit after a failed startup. Stewart Butterfield did something smarter.

He shut down a failing video game and noticed one thing his team couldn’t live without. A simple internal messaging tool. That tool became Slack.

The lesson is simple. Pay attention to what actually works, even if it was never part of the original plan. Some of the best companies are born from pivots, not pitches.

Sharing a short video on how failure quietly built one of the most used workplace tools today.

(or: why AI isn’t cheating, unless you’re allergic to output)

I keep encountering fascinating creatures on Tumblr. Some of them believe that using AI for anything creative is “cheating” — but not using brushes that paint grass, or circle tools, or copyrighted textures from some app’s material pack. Those are fine. AI though? That’s a bridge too far. Suddenly, we’re “asking someone else to draw something for us.” Apparently.

What’s fascinating here isn’t just the logic gymnastics. It’s the mindset. These people aren’t thinking in terms of results — they’re still deep inside the cult of process. If you skip the process, you’re cheating. If you get a result too fast, too easily, too beautifully — that result must be illegitimate. The holy grail isn’t output. It’s suffering.

I get it. Some people find meaning in the struggle. But here’s the thing: I work in a product team. In IT company. Where we have deliverables. Deadlines. Users. Releases. If we launched something fast and it worked? That’s a fucking win. No one ever says: “Well, we could ship it now, but let’s delay three weeks so the designers can suffer more and the developers can touch more pixels manually.”

If you come to your stand-up and say, “We’re not ready — but we explored 14 dead ends and hand-coded everything from scratch,” the room doesn’t applaud. The PO doesn’t throw confetti. You don’t get bonus points for inefficiency. We’re here to build something that works, not to cosplay 18th century oil painters.

And that’s why arguments like “AI art is cheating” feel so disconnected from how real creative work happens in tech. We don’t fetishize the method — we care if it ships. We care if it solves a problem. We care if it lands.

If you’re angry that someone finished their illustration in 30 minutes while you’re still sketching the same eye for the third day — maybe the problem isn’t their tool. Maybe it’s your expectations.

Because you think this is a test of patience. They think this is delivery.

What is the gap to close if switching from visual to product design? This is a familiar question from graphic designers who intend to transit.

I taught visual design for 5 years before I switch to the industry. Initially I was doing web and UI design as well. Little did I know UI is far different from UX design. Working as the solo designer at a startup helped me to be well rounded, but the best way to learn product design is to join a company with a group of designers who have built great design systems or elegant products.

I worked for 3 startups from different stages and I learned many different things from each company. If I have to summarize the gap that I have to close, it’s interaction design and product thinking.