Product Design for Startups

Product design for startups is not a coat of paint.

It is how an idea becomes something a customer can use, a team can ship, and a company can grow — without spending the round on screens that never earned their place.

I work with seed to Series B founders as fractional product and design leadership: strategy, interaction design, and enough code to make the idea real. One person. End to end. No junior account team in the middle.

If you are trying to turn an idea into a product, a product into a prototype people will actually react to, or a working product into UX that can scale — that is the work.

What product design means here

In an early company, “design” often gets treated as UI. A set of screens. A cleaner dashboard. A pitch deck that looks like a product.

That is not the job.

The job is to decide what the product is for, cut everything that does not help you learn that, and make the remainder real enough that a human can use it. Then you watch what they do. Then you decide what deserves to be built next.

Most products do not fail because they were ugly. They fail because too much got built before anyone knew whether it mattered.

So the work looks like this:

• Find the assumption carrying the most risk
• Reduce the idea to the smallest thing that can test it
• Make a prototype or a v1 people can actually use
• Put it in front of real users
• Follow the evidence — including the evidence that says stop

How I work is the method. This page is what that method is for.

Who this is for

I work with founders and CEOs from first idea through Series B — the stretch where the product is still being invented, and the cost of a wrong shape is still recoverable.

Seed

You have an idea, a wedge, maybe a few conversations. You do not need a 40-screen product. You need a clear problem, a focused first version, and something real enough to test, fund, or launch.

Typical outcome: a Product Sprint that turns “it’s in my head” into a direction you can stand behind — and a prototype that answers the question you were avoiding.

Series A

Something is live. People are using it, or about to. The original story is colliding with real behaviour. The product has grown faster than the thinking.

Typical outcome: an MVP you can put in customers’ hands, or a rethink of the experience so the core workflow is obvious again.

Series B

The product works. That is now the problem. Workflows have accumulated. Teams have multiplied. Every new feature has a shadow feature attached. UX is no longer a screen. It is a system.

Typical outcome: senior product leadership inside the team — unpicking complexity, setting the next product decisions, and building the foundations so the experience can scale without becoming a maze.

If you already have an in-house team, I sit beside them. If you do not, I cover the gap without turning you into an agency client.

Ideas into products

Turning an idea into a product is not “write a spec, then design, then build.”

It is finding the one thing the first version has to prove.

That might be whether customers care. Whether they understand the proposition. Whether the workflow makes sense. Whether AI can actually do the task. Whether the business model works at all.

Until that question has an answer, a bigger product is just a more expensive guess.

A recent 0→1 example: Petlio — a two-sided marketplace for pet care — went from idea to a live product in 21 days. Not because speed is the point. Because the only way to know if a marketplace is real is to let both sides use it.

Another: Pledge My Tree — a concept for making environmental commitments visible — was a four-day prototype. The product decision was honesty: pledged is not planted, planted is not verified. The interface followed that, not the other way around.

That is 0→1 product design. Reduce the story until it can be tested. Make it. Learn. Then decide.

Prototypes that answer a question

A prototype is not a performance.

Documents are useful for thinking. They are terrible substitutes for products. People react differently to something they can actually click, complete, or abandon.

Fidelity should follow the question, not a process:

• If you are testing understanding, a sharp flow beats a polished visual system
• If you are testing an AI task, a working agent beats a clickable mock
• If you are testing whether anyone comes back, you need something they can return to

Rough behind the scenes is fine — if the experience in front of them is coherent.

I will not spend weeks making a prototype that could have answered the question in days. I also will not ship theatre: a beautiful walkthrough of a product nobody has tried.

The output is something real enough to experience, challenge, and test. Then we read behaviour, not opinions.

UX that can still scale

Scalable UX is not “more screens, more consistent.”

It is the difference between a product that can take the next fifty customers and a product that collapses under its own options.

As companies move from seed to Series B, the failure mode changes:

• Early: you built the wrong thing, very carefully
• Later: you built too many right-looking things, and nobody can find the one that matters

Scalable UX means:

• A core workflow that stays obvious as the product grows
• Information architecture that can absorb new jobs without a redesign every quarter
• A design system that lets the team ship without inventing a new pattern each time
• Product decisions that protect the experience when the roadmap gets loud

This is where fractional leadership earns its keep. You do not always need another full-time hire. You need someone who can sit in strategy and in the pixels — and say no to the work that would make the product harder to use at the next stage of scale.

Raiqa is the long version of this: from early concept to a live AI-native healthcare ecosystem. The design problem was not a screen. It was an ecosystem — patients, practitioners, agents — that had to stay intelligible as it grew.

How the work actually runs

I do not run a rigid six-phase process. Depending on the product we might move forward, jump backwards, or run several things at once.

The goal is not methodology. The goal is to reduce uncertainty.

In practice the moves are:

1. Find the question carrying the most risk
2. Cut the scope to the smallest thing that can answer it
3. Make it real — prototype, working v1, or an agent doing a real task
4. Test it with people who do not work at the company
5. Learn from what they do, not just what they say
6. Decide — build, change, or stop. All three can be good outcomes

AI changes the speed, not the standard. First drafts — market scans, design exploration, code scaffolding — come back faster than they used to. I still review, direct, and ship every deliverable against the same bar I would hold an in-house team to.

Speed is useful. Unexamined speed just ships confusion at a higher frame rate.

How we typically start

You do not need a brief. You need a situation.

Product Sprint (2–4 weeks) — You have an idea. We find the product before you fund the build: a clear problem, a focused first version, a prototype ready to test.

MVP Launch (4–10 weeks) — You have direction. We take it to a working v1 people can use: designed, tested, ready for real users.

Fractional Product Lead (ongoing) — You have a team, or you are about to need one. I work alongside you to make better product decisions, unstick the hard problems, and keep the important work moving — without a full-time hire.

If you are not sure which one you are in, that is a normal place to start. Tell me what’s going on. I will take it from there.

What you should expect from me

• Strategy, design, and code from the same head — no telephone game
• A smaller first version than you were imagining, on purpose
• Something you can put in front of users, not just stakeholders
• Honesty when the evidence says stop — even when that means recommending less work
• A product that can grow without becoming a pile of screens

I have been building products for twenty years, launched 14+ startups, and stayed in the work because the interesting part is still the same: turn complexity into something people can understand and use.

The industries change — healthcare, financial crime, government, video, AI. The pattern does not. Competing constraints. Difficult workflows. Too many ideas. My job is to find the signal and make it shippable.

If this is the work you need

You do not need more screens.

You need a product decision you can stand on, a prototype that tests it, and UX that will still make sense when the company is bigger than the room you are in now.

Start a conversation. Bring the messy version. That is enough.