After three months working as a Product Designer for a SaaS startup, I can say I deliberately sought a startup environment because the learning potential, and therefore long-term ROI, are much greater than a big company.
Very few medium and large companies enable learning like startups do:
- Work moves fast
- Money is tight
- Founders may announce "guys, we only have two more weeks of cash. So we either make something up fast or we can all start polishing our resumes"
Despite holding the title "Product Designer," I performed tasks ranging from designing (typical designer work) to defining important product outcome metrics based on main business outcomes — work typically belonging to Lead Product Designers or Heads of Product.
1. Before scaling, there isn't enough time for polishing
Startups move fast. Their thinking might resemble: "We got funding (or we're about to get it), we need to show what's up. We need to get users, roll features out, improve the product, improve our architecture, set ourselves up to scale. Let's do all these projects. At once. All together. Everything is a priority. Go!"
With two designers (the manager being Head of Product and Design, focusing equally on strategy), we churned out incredible work in three months. No time for polishing existed.
A startup's job isn't having the best possible interaction — it's validating its Value Proposition to achieve critical Product-Market Fit. Therefore, understanding "what moves the needle" for business becomes paramount.
There will always be one million things to do, and as a Product Designer, or Product Manager, it is your job to understand what really moves the needle and make sure the right things are being built. Is what you're spending your time on really adding value to your user? Is it helping the startup to validate their Value Prop? Whenever anything you're doing doesn't lead to true value, you should do your best to not do it.
"Focus is about saying no" — Steve Jobs
2. Disagree with questions, not statements
Teams frequently disagree — especially in startups. This proves totally fine. No one wants to work for companies where highest-ranking people throw ideas out there expecting everyone's agreement.
When disagreeing, ask teammates their reasoning and throw in thoughts as questions:
- "Have you considered X, Y, and Z?"
- "I hear you, but recent interviews we did with users showed A and B. How are we supposed to do X when recent A/B tests have proven that Y would be a better solution?"
Well-placed questions lead teammates to think more deeply about decision reasons, often resulting in interesting debates.
Disagreeing strongly — even though you might be right — doesn't really lead anywhere good in the long term. But always agreeing is even worse. You don't want to be that person that always agrees.
3. It's on you to create the culture and process
You work for a startup, not a large corporation. Culture and process (the word "process" feels big company-like — "the way we do things" fits better) are still very fresh and maybe nonexistent — especially when you're the second person joining the Product/Design team.
You don't want to be the designer who just works and doesn't influence how the sausage is made. Especially where you have the chance to.
Read, get informed, talk to other people about their work approaches, and bring learnings in-house. Long-term, you'll be appreciated for doing more than just your job and setting companies up for scalability.
4. Data and reasons are your most important allies
Imagine presenting a workshop to founders and important stakeholders who ask: "I've seen another version of this page in the Design File and I liked it better than this one. Why did you decide to go with this one?"
Having answers to such questions is crucial — but not just opinion. Come with the data. Support your opinion with user research. Always.
I can't stress this enough. Come with data and research arguments, and your stakeholders not only will be happier with the product decisions, but they'll give you more room for decisions and exploration rather than trying to intervene since they don't know what is going on with the product.
5. Share work often with stakeholders
After having work doubted multiple times, I closed feedback loops after sprints and questioned why stakeholders doubted designs and gave many pushbacks.
The main reason? The lack of continuous knowledge sharing with stakeholders.
Previously, my mindset was "I did the research, defined the problem I'm trying to solve, explored widely the solution space, and now I'm just presenting designs to stakeholders. This is what is going to be built. This is just a formality."
When presentations came, did designs actually get built? Sometimes yes; other times, no — due to stakeholder pushback.
By sharing work weekly and supporting design/product decisions with past discoveries (which stakeholders remember from previous reviews), team dynamics transformed from:
You vs them, with you trying to get approvals by shoving work in their face
to
All of you being an actual team, collaborating to achieve product outcomes and company missions.
Continuous sharing improves company image, increases collaboration, and above all — creates more user value by sharing important knowledge and work with your team, which will then apply that customer knowledge to their decisions.
Everyone wins.
