Products rarely lose coherence all at once. As momentum grows, feature requests accumulate and developers keep shipping each locally reasonable addition until the main journey loses priority. Product design is the ongoing practice of stepping outside the implementation, judging each addition against the whole experience, and deciding what belongs before another feature reaches production.

This guide focuses on what to do next. If you want to understand the problem first, read The Feature Works. The Product Doesn’t.

Start with the problem, not the feature

Feature requests often arrive disguised as certainty. By the time work reaches a developer, a proposed solution can look settled even when the underlying problem is still vague.

Before you add another route, component, or data model, make the problem specific. Who is this for? What are they trying to do? Where does the current experience break down? What would become meaningfully better if you solved it? What does the person need to understand, trust, or accomplish?

If those answers aren’t clear, adding more screens only gives the product more surface area. The feature may work perfectly while the product around it becomes harder to understand.

A clear problem gives you something to evaluate. A feature request only gives you something to implement.

Choose the primary outcome

Every feature has its own logic. A growing product still needs a hierarchy.

Keep returning to the primary outcome: the thing someone should accomplish that makes the product worth using. Then protect the happy path, the shortest coherent route from their starting point to that value.

The happy path isn’t the only path you’ll build. It establishes what the rest of the product is supporting. Onboarding, navigation, empty states, permissions, errors, and settings should help someone reach the outcome or clearly explain why they can’t yet.

Without a primary outcome, each addition can demand equal attention. Navigation grows, controls multiply, and the product leaves people wondering what to do next.

Explore alternatives before implementation creates commitment

Once a feature enters the codebase, it accumulates gravity. Components exist. State has been wired up. The API shape starts reflecting the interface. Even if the direction weakens the product, replacing it now feels wasteful.

Explore before that happens. Use Paper, Figma, FigJam, a whiteboard, or anything that lets you see several directions at once. The tool matters less than the distance it creates from your first answer.

Look at references too. See how competitors and other great products solve similar problems. You’re not looking for something to copy. You’re trying to understand the patterns people already know, what seems to work, and where there might be room for a better answer.

Good references also give you more than your first idea to work from. Pull from products inside your category and outside of it. Sometimes the best solution to a trading problem comes from a game, a social app, or a completely different kind of product.

Make those directions meaningfully different. Try another information structure, a different core action, a shorter journey, or a different way to explain the product. Three versions of the same screen with different button styles aren’t three product directions.

AI can help you create breadth quickly. Ask it for several interpretations, not endless polish on the first one. Generation gives you options. You still have to decide which option best serves the problem and why.

Use a simple checkpoint before committing. It keeps a locally sensible addition from becoming permanent simply because it already works:

  • Keep: The convention already carries clarity, speed, or trust.
  • Refine: The structure belongs, but the hierarchy, language, feedback, or quality needs work.
  • Rethink: The purpose, flow, product model, or signature moment needs another answer.

Map the journey, not just the components

Developers naturally think in routes, components, and data states. People experience the seams between them.

A component can work in isolation while the journey around it fails. Context disappears between screens. The next action is unclear. Feedback arrives too late. A risky decision asks for trust before the product has earned it. A Storybook story can prove that a component renders correctly; it can’t prove that the experience makes sense from beginning to end.

Map the meaningful actions, decisions, system responses, waiting states, failures, and success states along the journey. Put the full sequence somewhere you can see it at once.

Then ask the obvious questions. Does the person know what’s happening while they wait? Do they know what to do next? Is the feedback sufficient? Are wins acknowledged? Are risks and consequences clear? Can they recover from a mistake? Could a step be removed, combined, delayed, or reordered?

These aren’t polish questions. They determine whether a set of working components becomes a coherent product.

Prototype the riskiest assumption

Developers often prototype technical feasibility: Can the API return the data? Can the model produce the output? Can the interaction run at 60 frames per second?

Product prototypes answer a different kind of question. Will someone understand the next step? Will they trust the transaction? Can they recognize the value? Does the new behavior feel useful enough to replace what they do today?

Test the riskiest assumption before you build the entire system around it. A click-through prototype, a rough canvas, or throwaway code can be enough. Put the direction in front of people, watch where they hesitate, and revise the product rather than automatically explaining the confusion away.

A prototype should reduce uncertainty before it creates commitment. If you’re already protecting its architecture, you’re probably building too much.

Bring the decisions into code

Once a direction survives comparison and testing, bring it into production. Implementation is where the idea meets real content, responsive layouts, accessibility, performance, loading, errors, permissions, and messy data.

That makes code another test of the product decision. Does the hierarchy survive a narrow screen? Do loading and error states preserve the same intent? Does the interaction still feel trustworthy when it takes longer than the demo? Does the distinctive moment remain useful after the novelty wears off?

Keep the reasoning close to the implementation. The team should still know which outcome the feature supports, which trade-offs were deliberate, and which parts need evidence after launch. Otherwise, product decisions disappear one small implementation choice at a time.

After launch, use behavior and feedback to find where the journey breaks down. Shipping gives you evidence about what to keep, refine, or rethink next.

Spend craft deliberately

Once the journey and its trade-offs are visible, decide where the experience should be familiar, where it deserves more care, and where novelty is worth its learning cost. Not every interaction needs to become a signature moment.

Expected

Expected moments use patterns people already understand. Navigation, inputs, settings, search, account management, and routine confirmations usually benefit from platform conventions and familiar components.

Expected doesn’t mean neglected. It means you’re choosing reliability where reliability creates the better experience.

Elevated

Elevated moments keep the underlying interaction familiar while adding more care, clearer feedback, personality, or emotion. A pending action can explain what’s happening. A milestone can feel more rewarding. A risky decision can slow down and give someone enough context to proceed confidently.

The pattern remains legible, but the moment feels specific to the product. This is where much of its personality can live without asking people to learn a new interaction every time.

Net-new

Net-new moments introduce an experience someone hasn’t encountered before. Reserve them for interactions that are central to the product’s value or identity, especially when the moment is worth remembering or sharing.

Novel interactions also create implementation and learning costs. When every part of the product tries to be original, the experience becomes exhausting and the codebase becomes harder to maintain. A few genuinely new moments stand out because the rest of the journey gives them room.

Most of the journey should remain Expected. Some moments should be Elevated. Very few need to be Net-new. That ratio isn’t a law. It forces you to decide where familiarity helps, where additional craft matters, and where novelty earns its cost.

Protect coherence as the product grows

Product design for developers isn’t one phase at the start of a project. It’s a recurring check on whether each addition strengthens the product or merely expands it.

Before implementation, design identifies what deserves to exist, compares possible directions, and exposes weak assumptions. During implementation, it protects the hierarchy, journey, states, and trade-offs that made the direction worth choosing. After launch, it gives the team a clear model for interpreting what people do next.

Momentum is useful when the product still has a clear direction. Give each addition a reason. The code should carry a decision you can explain, not another feature that happened to fit on the roadmap.

Product Judgement Skills

The process above still works on a canvas. I built the Product Judgement Skills so developers wouldn’t have to leave the IDE to use it.

When implementation is cheap, the easiest thing to skip is the pause before you write the feature. Opening Figma, writing a spec, or waiting for a review can all feel like leaving the work. So the model gets asked to build, and product judgment happens later, if it happens at all.

These Skills keep that judgment in the same loop as the code. You can prompt for the problem, the journey, the screen, the reason to return, or where craft belongs—without switching tools.

  • Compass maps the product journey and helps you see where the experience breaks down.
  • Focal clarifies what each screen needs to communicate and what users should focus on.
  • Flywheel examines what gives people a reason to come back.
  • Soul helps you decide where the experience should stay Expected, become Elevated, or feel Net-new.

Point them at a design, a product requirement, or the code in front of you. They’ll help you explore alternatives, protect the main journey, and spend craft where it matters. The final judgment is still yours.

AI can make every addition cheap. Product design helps developers decide whether each one makes the whole product stronger.

Try this before your next feature

Stay in the editor. Point the Product Judgement Skills at the addition you’re about to write, and ask for a product decision instead of an implementation.

  1. Compass: “Here’s the feature I’m about to add. Map the journey and tell me whether it strengthens the happy path or creates another competing one.”
  2. Focal: “Look at this screen. What does it need to communicate, what can wait, and where should attention go?”
  3. Flywheel: “After this change, what reason does someone have to come back? Where does the flow lose momentum?”
  4. Soul: “Which moments here should stay Expected, which deserve to be Elevated, and is anything actually Net-new?”

If the question crosses scales, run Product Judgement and get one prioritized sequence. Then decide. The Skill can surface options. It can’t own the call.