Design Was Never the Problem. Alignment Was.

Most founders fall in love with their idea before they fully understand it.

I’ve worked with quite a few early-stage founders, and this is something I keep seeing. The intent is always there, the excitement is real, but when you start going deeper into what they actually want to build, you realise they are only looking at one part of the problem. The part they understand. The part they are imagining.

The rest of the system, how things connect, what happens when real users start using it, that is still blurry.

And that is where things usually start breaking later.

The approval problem

In the early days of my career, I thought I was doing things the right way. I would take detailed requirements, align with stakeholders, get approvals, and then start designing.

But even after all of that, projects would still go through rework.

Something new would come up at the last moment. A developer would point out a limitation. A stakeholder would say this is not what they had in mind. It used to frustrate me because on paper, everything was already approved.

Over time, I realised the problem was not in the process. It was in the alignment.

We were aligned on documents, but not in how we were thinking about the problem.

The understanding document

That’s when I started changing the way I approach projects.

Now, whenever I get requirements, I don’t just consume them and move ahead. I rewrite them in a way that forces clarity. I create what I call an understanding document. It is essentially the same requirement, but structured like a story, with all the gaps still visible. And alongside that, I add questions wherever something feels unclear or assumed.

I share this with the client and give them time to go through it properly.

And then we sit together.

What a workshop actually is

That session is what I call a workshop.

Not a presentation. Not a status update. Just a working session where everyone involved is part of the conversation.

The goal is simple. Before we build anything, we make sure everyone is actually on the same page.

Because most of the time, ambiguity is not in what is written. It is in how different people interpret the same thing.

During these workshops, we don’t just talk about features. We walk through real scenarios. We question assumptions, we pause on things that don’t feel clear, and we force decisions where earlier there were just loose ideas.

And this is where things start to shift.

People who would normally just review designs later, start contributing early. They start thinking through the problem, not just reacting to a solution.

The e-commerce project

I remember one particular project with a startup founder.

They came to me with what sounded like a simple requirement. They wanted to build an e-commerce website. Typical flows, product listing, product details, checkout. Nothing unusual.

If we had started designing immediately, we would have built exactly that.

But during the workshop, as we started discussing how this would actually work in real life, things started opening up.

Questions came up around how orders would be managed once they start coming in, how inventory would be tracked, what happens when something goes out of stock, how sellers would update their products.

These were not edge cases. These were fundamental to the product.

But none of this was part of the original requirement.

That’s when I pointed something out.

What they were trying to build was not just a website. It was an entire system.

An order management system, an inventory system, a seller management layer. And building all of this from scratch is a very different problem than building a simple front-end experience.

So I suggested that instead of building everything from scratch, we consider using something that already solves a large part of this problem. Platforms like Shopify already handle most of these things really well.

The founder was a bit taken aback at first. Because in their head, the goal was to build their own platform. That was the idea they had come in with.

But once we walked through the implications, the time, the effort, and the complexity involved, the conversation shifted.

They decided to go ahead with Shopify.

If we hadn’t had that workshop, we would have easily spent weeks designing something that was incomplete. Or worse, something that would have needed a complete rethink once development started.

Why this changes things

When people are involved in shaping the solution, their relationship with the work changes. They don’t feel like they are reviewing someone else’s output. They feel like they are part of building it.

That sense of ownership makes a big difference.

Feedback comes in earlier. Conversations become easier. There are fewer surprises.

Over time, I started seeing a pattern.

Less rework. Fewer last-minute changes. A lot more trust within the team. Everyone knew what was being built and why.

How I run these sessions

I usually use tools like FigJam for these sessions, and sometimes even simple sticky notes do the job. The tool itself doesn’t matter as much as the environment you create.

I like to start with something light, usually asking everyone to draw something. It sounds small, but it works. People loosen up, the room feels less formal, and the conversation becomes more open.

Over time, I’ve experimented with different ways of running these sessions. Sometimes it looks like a simple brainstorming exercise, sometimes closer to design thinking where we break the problem down and rebuild it together, and sometimes it’s just walking through user journeys and questioning every step.

There is no fixed format. The structure changes depending on the problem and the people in the room.

These workshops help uncover gaps early, bring in more use cases, and push everyone to think from the user’s perspective. You start considering edge cases before they become problems.

By the time you move into design or prototyping, you are not guessing anymore.

You are building with clarity.

Workshops are not about sticky notes.

They are about making sure that no one says “this is not what I expected” after weeks of work.