Hey and welcome back to a new week!

In this issue:

• Do You Know What To Expect From The Job? I found myself surprised by a lot of aspects of the job once I had one. This way you go in prepared.

• Karen’s Portfolio: Another excellent example of a multidisciplinary designer pulling it off perfectly!

Thank you for reading!

🌊 MY ADHD USED TO HOLD ME BACK - NOT ANYMORE

ADHD management designed for how your brain actually works

Most ADHD apps are just glorified timers. Inflow is different - built by people with ADHD, backed by clinical psychologists, using CBT-inspired strategies. Learn to manage time blindness, burnout, overwhelm, and procrastination in 5-minute daily modules. Real tools, real change.

Take the free quiz.

What Product Design Work Actually Feels Like Once You’re In 🧩

A lot of people spend years trying to get into product design without ever getting a clear picture of what the work actually feels like once they land there.

You see polished portfolios.

You see tidy case studies.

You see beautiful interfaces.

You see job titles that sound exciting.

And it’s easy to imagine the role as a kind of endless stream of thoughtful flows, nice screens, and clever interactions.

That is not really what the job feels like.

Not because the work is bad. I still love it. But because the reality is much more structured, much more collaborative, and often much less glamorous than the path into it makes it seem.

And right now, that reality is shifting again.

First: product design usually means the product, not the marketing site

When people say product design, they usually mean working on an actual digital product.

Not mainly the website.

Not mainly brand.

Not mainly campaigns.

Of course there are overlaps. Especially in startups, you often wear more hats and end up touching the website too. But when we talk about product design as a role, we’re mostly talking about functionality.

Flows.

States.

Logic.

Complexity.

Things that need to be mapped carefully because real people are trying to do real things inside the product.

That’s the center of gravity.

This is also why I sometimes see portfolios miss the mark a bit. People show mostly website projects and try to present them like deep product design case studies. And that usually falls apart because a website just often does not go nearly as deep functionally as an actual app does.

That doesn’t mean website work is useless. Not at all. If you worked on a real marketing site and drove real outcomes through it, better conversion for example, that can absolutely be a strong project. And there are definitely jobs where that kind of work is central. They just tend to be less common, and often they sit under slightly different titles.

But if your portfolio mainly shows websites and you’re applying for roles where the actual job is inside the product, that is usually a problem.

The biggest shock is usually cross-functional collaboration

If you haven’t had an internship yet, or haven’t worked inside a company, most of your experience so far has probably been one of these:

• working alone

• doing portfolio projects

• maybe doing university group work with other designers

All of those are different from the real thing.

Because in actual product teams, your main collaborators usually are not other designers.

They are:

• product managers

• engineers

• sometimes product owners

• sometimes analysts

• sometimes a researcher if you’re lucky

There may be other designers around, yes. But often you’ll mostly see them in critique, reviews, or other design-focused meetings. The actual day-to-day work tends to happen cross-functionally.

And even that has been shifting. We are moving more and more toward setups where a pod or squad has one designer, not several. Researchers and specialists are less often embedded directly too. In startups this has been normal for a while. In bigger tech companies, you still see more support structures, but even there the trend is moving toward leaner teams.

So no, you’re usually not sitting in a cluster of designers making polished flows together all day.

You are often the only designer in the room.

And that means your closest collaborators will think very differently from you.

The PM, the engineer, the analyst, they may all value design. They may all be happy you’re there. They may all want you to do good work.

That does not mean they think like you.

And it definitely does not mean they will agree with you by default.

They often have very different ideas of what the right thing to do is, how fast something should move, how much detail matters, and where design effort should go.

That’s not a flaw in the system. That is the system.

You are all looking at the same problem from different angles.

Especially with engineers, this can be a shock for juniors. I’ve had many reach out after starting their first role because they suddenly struggled with developers being opinionated, blunt, dismissive, or simply focused on completely different constraints.

Some environments are much better than others, obviously. Still, this is something you have to learn. And there is no perfect way to prepare for it from the outside.

What you can do is go in with the right mindset.

Your PMs and engineers are not enemies.

They are your closest collaborators.

You want to understand how they like to work, what they expect from design, and what kind of input they find useful.

Whenever I join a new team, or someone new joins mine, I like to have exactly those conversations. How do you like working with design? What do you want from me? What helps you? What annoys you? Where do you expect me to push harder?

That does not mean bending yourself into whatever shape everyone wants. But it does mean learning how to collaborate instead of assuming the collaboration will sort itself out.

It usually won’t.

A lot of the job is deciding, aligning, and protecting focus time

Another thing people don’t always expect is how awkwardly the role sits between PMs and engineers.

Engineers often get more protected focus time because their role is more purely executional.

PMs often live in meetings because their work is planning, alignment, prioritization, and decisions. Their output is often a decision, and a decision can happen in a meeting.

Design sits in the middle.

You need execution time.

You need focus.

You need time to think, make, test, refine.

But you also need to be part of the conversations that shape what gets built in the first place.

That means meetings are both useful and dangerous.

Useful, because being in the right conversation early can save you from a lot of nonsense later. Dangerous, because depending on the company, meetings can become a giant time sink and you end up trying to design in the half hour between two calls, which is one of the most miserable ways to work.

I’ve done that. It’s terrible.

So one practical part of the job is learning to shape your calendar, even if only gradually.

Talk to your PM. Make sure they know you want to be brought into the conversations where design perspective matters. At the same time, block real focus time in your calendar. Not tiny decorative slots. I mean two-hour blocks at least.

Anything less and the day gets shredded.

And no, you probably won’t spend most of your time in Figma forever either.

Figma still matters. I still use it to sketch, ideate, lay things out, and create a source of truth. But some of the time that used to sit there now sits somewhere much closer to code.

Sometimes that means writing first. Clarifying the problem in words. Thinking through a flow before making anything visual.

And increasingly, some of the work moves into tools like Lovable, Cursor, Claude Code, or whatever environment gets you closer to something functional faster.

That might be:

• a lightweight prototype for early validation

• something internal to align a team

• a coded component for a design system

• or even, occasionally, a small piece of production code

I’ve done all of those to some degree.

To be clear, I’m not hand-writing all that code from scratch.

That’s not the point.

The point is that the job is moving toward a world where being comfortable around code matters more. Seeing it, understanding roughly what’s happening, using AI to guide it, and helping bridge the gap between intent and implementation.

That transitional layer between “what should this do?” and “how does it get built?” is becoming a very valuable place to operate from.

And I think in two years, saying this won’t feel remotely special. It’ll just sound normal.

A lot less of the job is flashy than people imagine

This is maybe the part that disappoints people the most.

Do you get to pour all your craft into beautiful little details, intricate interactions, and polished moments all day?

Sometimes.

But in most organizations, not nearly as much as people think.

If you work at a place like MetaLab, Shopify, Vercel, or somewhere else with a very high design bar where expressive quality is part of the actual product expectation, then yes, that work is much more central. Even then it’s still purposeful. It’s not portfolio design. But it is part of the job in a bigger way.

In most places, though, product design is much less fancy than the hiring process makes it seem.

Your portfolio might need to be highly polished, memorable, and visually sharp to get you in the door.

The actual job might be rebuilding an internal workflow, improving a settings page, fixing a broken signup step, or making a dense enterprise flow less painful.

And when you want to spend extra time refining a beautiful interaction for an empty state, the PM and the engineer may quite reasonably ask why that matters right now when the main flow still isn’t resolved.

That tension is real.

There is usually room to push for better craft. I think designers should push for it. But it’s a balance. And especially as a junior, when everything takes longer already, that balance can be hard to strike.

This also depends heavily on where you work. A consumer-facing company with a strong product brand may give you more room for this earlier. A large company where you’re working on internal or systems-heavy tooling may barely care about those details for a long time, even if you do.

And that leads to one of the weirdest truths in the field:

the skills you need to get the job are often not the same as the skills you need to do the job.

It’s a stupid paradox, honestly.

You may need a visually exceptional portfolio to get hired into a role where the day-to-day work is mostly about structure, collaboration, tradeoffs, and shipping something that is useful but not especially glamorous.

That’s frustrating. But it’s real.

And even when you care deeply, the final product may still not match your standards. Spacing off, states missing, details ignored because nobody wanted to spend time on them. This is especially common in less design-mature environments.

The upside is that as designers get closer to code, some of this changes. If you can prototype closer to the real environment, contribute components, or at least understand implementation much better, you have more leverage. You can close the gap more effectively.

That is one of the biggest real changes happening right now.

So what does the job actually feel like?

It feels less like sitting around making beautiful mockups.

It feels more like:

• talking to PMs and engineers

• understanding constraints

• writing and thinking before drawing

• protecting focus time

• making decisions with incomplete information

• aligning people who think differently

• sometimes building closer to code

• sometimes fighting for quality

• and often working on things that are less sexy than the portfolio that got you hired

If you came in mainly for the visual side, the reality can feel harsher.

If you like systems, collaboration, ambiguity, and shaping messy things into something usable, the job starts making a lot more sense.

That doesn’t mean the visual side disappears. It still matters. A lot. But it’s not the whole thing, and in many teams it’s not even the center of the job.

The center is usually this messier space between product intent, business goals, technical constraints, and user reality.

That’s what product design work actually feels like once you’re in.

🦜 AS A YAPPER THIS IS A BLESSING

Stop typing what you could say in 10 seconds.

Wispr Flow turns your voice into clean, professional text inside any app. Emails, Slack, client updates — speak once, send without editing. 4x faster than typing.

Try Wispr Flow free

👀 Portfolio Showcase

Today: Karen Lou

Karen Lou is still studying at the University of Southern California, but her portfolio already feels like it was put together by someone who understands how to shape an experience, not just present work.

There’s a strong sense of intention throughout. The work spans product, visual, motion, and marketing design, yet it doesn’t feel scattered. It feels cohesive. More importantly, it feels like it comes from one perspective. You can tell she’s not thinking in strict disciplines, she’s thinking in outcomes and expression.

What stands out early is how inviting the portfolio is. It doesn’t overwhelm, it doesn’t overexplain, and it doesn’t rely on heavy styling. It pulls you in with small moments, and once you’re in, you want to keep going. That’s not easy to achieve, especially at this stage.

That’s it for this week—thanks so much for the support! ♥️

Do you want your own portfolio reviewed in-depth with a 30-minute advice-packed video review? Or do you require mentoring to figure out a proper strategy for your job search?

I got you!

• Book an in-depth portfolio or resume review with me

• Book a mentoring session with me

• Book a quick 15 min chat to ask a question and see if we vibe

Keep kicking doors open and see you next week!
- Florian