· 4 min
Ten Years of Product Design
What startups, scaleups, and large companies taught me about ownership, collaboration, systems, and impact.
Startups taught me ownership
In a startup, there is rarely a perfect brief waiting for you. You learn to find
the problem, ask the first questions, and move from an idea to something people can
react to. Design is close to the business because the distance between a decision
and its consequence is short.
That closeness is demanding, but it is also energizing. It teaches you to work with
incomplete information without confusing speed with care. You learn to make a
decision, explain the reasoning, test what matters, and change direction when the
evidence asks you to.
Ownership does not mean doing everything alone. It means taking responsibility for
moving a problem forward and bringing the right people into the decision.
The lesson I kept
Ownership does not mean doing everything alone. It means taking responsibility for
moving a problem forward and bringing the right people into the decision.
Scaleups taught me to build systems
As a company grows, the work changes. A solution that worked for one team or one
surface needs to become useful to several teams. New people join. Product areas
multiply. Decisions that once lived in conversations need to become patterns,
principles, and documentation.
This is where design systems became more than a collection of components for me.
They became a way to make good decisions repeatable. The goal was not to remove
judgment from design. It was to save judgment for the parts of the problem where it
created the most value.
Scale also taught me that consistency is not sameness. A strong system gives teams a
shared foundation while leaving room for product context, content, and real user
needs.
Big companies taught me influence
In a larger organization, good design has to work across more than the interface.
It has to move through existing systems, technical constraints, commercial goals,
legal requirements, and teams with valid points of view.
That can feel slower from the outside, but it gives design a wider responsibility.
You learn to facilitate alignment, make complexity visible, and create a path that
people can support. A workshop, a flow map, or a clear decision record can be as
important as a final screen.
Constraints make the work more real. They force you to understand how a product
operates and to design something that can survive contact with the organization
that has to build and maintain it.
The positive side of constraints
Constraints make the work more real. They force you to understand how a product
operates and to design something that can survive contact with the organization
that has to build and maintain it.
The common thread is not company size
Across startups, scaleups, and big companies, the strongest work has shared the
same ingredients: a clear problem, honest collaboration, enough contact with users,
and a team willing to learn after launch.
The tools and rituals change with the environment. In one place, a quick prototype
creates momentum. In another, a shared architecture prevents years of duplication.
Neither approach is universally better. The job is to understand what the product
and organization need at that moment.
This has made me less interested in defending one process. I am more interested in
choosing the lightest process that gives a team enough clarity to make a good
decision.
What ten years changed in my practice
A polished interface cannot rescue a poorly framed problem. Time spent clarifying
the outcome usually makes the design work faster, not slower.
A solution should be understandable, maintainable, and useful beyond the moment it
ships. Good handoff is not a document at the end. It is a system people can carry
forward.
Better outcomes include clearer decisions, less duplicated effort, more confident
teams, and experiences that help people complete what they came to do.
The biggest privilege of moving between company stages has been perspective. Startups
gave me urgency. Scaleups gave me systems. Big companies gave me patience and
influence. Together, they made me a more complete designer and a more useful partner
to the people I work with.
I look for the real problem earlier
A polished interface cannot rescue a poorly framed problem. Time spent clarifying
the outcome usually makes the design work faster, not slower.
I design for the team that comes next
A solution should be understandable, maintainable, and useful beyond the moment it
ships. Good handoff is not a document at the end. It is a system people can carry
forward.
I measure progress in more than pixels
Better outcomes include clearer decisions, less duplicated effort, more confident
teams, and experiences that help people complete what they came to do.