Claudio Lassala's Blog

I gave a talk at Side Project Society a couple of weeks ago, hosted at Improving. The room was packed, some familiar faces, some new. About half of the attendees were first-timers. That’s always a good sign.

The talk was about something I’ve been thinking about for a while: how easy it is now to build the wrong thing quickly.

You can watch the full presentation here if you prefer video.

The Wrong Plane

I started with a question: has anyone ever boarded the wrong plane?

I have. Fortunately, I caught it before takeoff. But the metaphor stuck with me. When you get on a plane, it goes really fast and really far. If you’re on the wrong plane, all that speed works against you. You land at the wrong destination, and now you have to make your way back. All the time you saved by flying? Gone.

That’s what’s happening with AI-powered development right now. We can build things faster than ever before. But if we’re building the wrong thing, we’re just getting to the wrong destination faster.

From Vibe Coding to Vibe Solutions

I asked the room: Who’s been “vibe coding”?

A few hands went up. I told them I don’t like that term.

Here’s why: when people say they “vibe coded” something, they usually mean they didn’t look at the code at all. They just told the AI to do something, and it worked. So they didn’t vibe with the code—they vibed with the solution.

That distinction matters. The code is just a byproduct. What matters is whether the solution actually solves a problem. Whether it fulfills a need.

I’ve been thinking of myself less as a software developer and more as a solution developer. The difference is this: a software developer focuses on the screen, the keyboard, the curly braces. A solution developer closes the laptop and talks to people. Reads body language. Watches for the moment when someone’s face does that thing—the visceral reaction that tells you there’s a real problem.

Need, Problem, Solution—In That Order

Most of us identify as problem solvers. I used to do that too. But I’ve started taking a few more steps back.

Behind every problem is a need. And we all suck at articulating that need.

We’re great at saying, “I want the following.” We write user stories like that: “As a user, I want…” But that doesn’t tell me the need. If I understand what you actually need, I can give you options. Short-term, long-term, maybe something you hadn’t considered.

Sometimes what looks like a problem from one angle isn’t a problem at all from another. So before we start building, we need to ask: what’s the need? What’s the actual problem preventing us from fulfilling that need? And only then: what are some possible solutions?

In that order. Don’t start with the solution.

A Real Example: Community Admin Headaches

I’ve been collaborating with Improvers involved in our Community Engagement. There are challenges: admin work, expense reporting, tracking attendance, making sure the pizza shows up, and making sure someone’s at the door with name tags.

And there’s a business intelligence blackout. We don’t have visibility into which groups are growing, which ones need bigger rooms, and which ones are thriving. We’re flying blind.

So we got together in a room for almost five hours. We didn’t take notes. We just had a conversation. We recorded everything.

I dumped the recording into my AI tool and said, “Create a vision statement. Create a problem statement. Extract personas. Write stories.”

It did all of that. Out of a conversation.

Then I told them: spec out a prototype. Don’t worry about databases or authentication. Just focus on what people will see and interact with. Build the parts that let us have a conversation.

It created stub data. It identified personas (the user group host, the organizer, the attendee). It built a clickable prototype with dashboards, checklists, real-time attendance tracking, and onboarding flows for new hosts.

I didn’t touch the code. I didn’t care about the code. What mattered was having something we could show people and say, “Does this look useful?”

Show, Don’t Tell

Here’s something I learned a few years ago: the elevator pitch isn’t what you think it is.

Most of us learned it this way: you get in an elevator with a CEO and have 30 seconds to explain your idea in words. You push out words and hope they form the right image in the other person’s mind.

But that’s not where the elevator pitch came from.

The original elevator pitch was from Elisha Otis, the guy who invented the safety mechanism in elevators. People were afraid of elevators back then. They wouldn’t get on them. The problem was clear: “I don’t want to be on that thing when the rope breaks.”

So Otis didn’t tell people about his invention. He showed them. He got on the elevator, went up, and told his assistant: “Cut the rope!”

The audience gasped. The safety mechanism kicked in. Otis didn’t fall.

That’s the elevator pitch. It’s not 30 seconds of words. It’s 30 seconds of wow.

When we pitch this idea to leadership, we won’t describe a dashboard. We’re going to pull up a prototype on a tablet and show them what it looks like. They’ll see the numbers, the insights, the checklist. They’ll say: “Tell me more.”

The Workflow That Makes a Difference

I thought about building tools to capture conversations. I tried different apps, different devices. Then I realized: I already have a voice recording app.

Now the workflow is simple:

1. Have a conversation. Record it.

2. Dump the recording into AI. Ask it to transcribe, summarize, and extract insights.

3. Build a prototype based on that conversation.

4. Show the prototype. Record the feedback.

5. Feed the feedback back into the AI. Update the prototype.

I’m no longer focused on taking notes during the conversation. I’m focused on steering the conversation. Asking the right questions. Making sure the person feels heard. Making sure they’ve expressed everything on their mind.

Later, I can sit with the transcript and ask my AI: “Explain this like I’m five.” I can make connections I didn’t see in the moment. I can run it against previous notes and see patterns.

And because I have the full transcript, I don’t lose anything. I used to write down what connected with me in the moment. But I’m a slow learner. Sometimes, the most important thing doesn’t click until weeks later. By then, it’s gone.

Not anymore.

From Stories to Graphic Novels

I’ve been experimenting with something new: turning user human stories into comic book-style storyboards.

I’m a visual person. When someone gives me words, my brain turns them into images. If I don’t know a word, I get stuck. The image stops forming, and I lose the thread.

So I wanted to take the prototype a step further. I wanted to show the overall experience—not just the computer screen, but the whole human experience.

I created a comic book-style walkthrough. Marcus, the first-time host, everything’s a mess. The AC wasn’t booked. It’s hot in the room. People are uncomfortable. Attendance drops. But the person who could fix it (the lady with three arms in the back office) doesn’t know it’s happening.

Then we show the ideal: Marcus has a digital checklist. Everything’s lined up. The pizza’s there. The event flows smoothly. Checklist complete.

Now we’re not looking at a computer screen. We’re looking for something that lets us collaborate creatively around the same vision.

What This Means for You

If you have a side project idea, here’s what I’d suggest:

Don’t start by building. Start by talking to people. Record those conversations. Look for the visceral reactions, the moments when someone’s face does that thing.

Ask yourself: what’s the need? Not the feature. Not the solution. The need.

Then ask: what’s the problem preventing that need from being fulfilled?

Only then: what are some possible solutions?

Use AI to help you prototype fast. But don’t vibe with the code. Vibe with the solution. Show people something they can react to. Record their reactions. Feed it back into the system.

And before you board the plane, make sure you know where it’s going.