Brian Lovin is a Product Designer building AI products at Notion, and someone whose thinking on how product design is shifting has quietly shaped how a lot of us are approaching the current moment.
We talked about job title, how to hire for beyond output, why side projects still matter, and what he’s noticed building for a global audience from the US while now seeing Europe up close.
Here’s the conversation.
— The Job Title Disruption
You’ve redesigned the designer workflow so that live prototypes ship in minutes. That quietly restructures the classic PM → designer → engineer triangle. Which part of the traditional product process do you think is the most ready for disruption, and what are PMs and product leaders still struggling to embrace or let go?
BRIAN: It’s really, really hard to predict anything right now. Anyone confidently predicting the future is not going to be right. We’re just in an interesting time where everything feels quite blurry, which is good.
Designers are certainly writing more code than they’ve ever written before, probably with the help of AI. More PMs are probably designing and prototyping than ever before with AI. Engineers, same thing.
So I think the biggest opportunity for disruption right now is people willing to break outside of their job title. Don’t be constrained by what your job title says you should do. If the goal is for us to build useful software that solves problems for people, and we finally have this set of tools that makes it really easy to step at least one step outside of your job title and try something, make something, that feels right for disruption.
And people seem to be doing that quite quickly. Everyone I talk to, designers are maybe even ahead of the curve on this, trying Claude Code and prototyping in code.
What product leaders need to adapt for is: how do we get to the point where designers can prototype something quite realistic and have it ship safely? How do we avoid it becoming slop? How do we avoid it causing a very long queue of code review, pulling in engineers to review sloppy work, not because the designer doesn’t care, but because the AI is still quite nascent, or the prompting was very exploratory and not intended to go to production?
All of a sudden, we need to take those ideas and figure out how to deploy them safely, make them secure, and not take up everyone’s time. If we can solve that, then you end up with more people able to contribute to a production codebase and ship features faster with less process. We have to figure out how to do it safely, with the right guardrails, and hopefully keep quality high.
— Hiring for depth
When AI handles execution, the things that actually matter shift, things like taste, judgment, curiosity, depth of experience. But those are notoriously hard to define and even harder to hire for. How do you actually assess whether someone has that depth? And do you think it can be developed, or is it something you either show up with or you don’t?
BRIAN: It’s a tough situation. I think the way you could have asked before — before 2023, maybe 2024 — was: “Have you shipped software before? Was the software good? Did it solve real problems?” And if the answer to those was yes, that person is probably well-known to have known how to ship things.
It became fuzzier during 2024, as more and more of this shifted to AI. I suppose the evaluation is still going to be fuzzy, but it’s something like: you’re going to know it when you see it. Has this person shipped a real thing that solves a real problem for real people? Have they worked on it for a non-trivial amount of time?
It’s easy to be a weekend warrior and bring a hacky project from your phone in 20 minutes. But can you iterate? Can you show it to your customers? Can you do it, do it, do it, do it? I think people who can talk about that, who can demonstrate they’ve done it over time, with or without AI, are in a great position.
The main thing for people using AI to make software for the first time, who might not have known how to make software before, is: can you do it while also building an understanding of how software works? You want to end up in a place where you understand the thing you’ve created and can iterate on it — without contributing to a mountain of tech debt that will eventually crumble, or is insecure, or will leak people’s information. You need to have some understanding of what’s happening.
I think it’s a special type of person who’s willing to go a little extra mile to interrogate what they’ve made with AI — to understand what’s happening underneath it.
— Side Projects as the New Portfolio
You’ve consistently shipped things alongside your main work — Shiori, Tax UI, App Dissection, Staff Design. Now that AI makes building cheaper and faster, is the side project becoming the new portfolio? What separates a side project that shows genuine potential from one that’s just a distraction?
BRIAN: I think side projects have always been a good thing to add to a portfolio. They’re never the only thing. Not every side project has to be a thing that makes money or has lots of users. It’s okay if it’s personal to you. The most compelling side projects are projects that solve a real problem, where you shipped something and then iterated on it a little bit. It’s not satisfying when people make something that didn’t solve a real problem, it just sounded like a fun idea, they made it in a weekend, and then... nothing.
So I guess that’s why side projects are super useful to have on a portfolio. They’re a way to demonstrate you have more reps in that process. But it’s not the only way. Obviously, in your main job you get lots of reps too. Side projects have always been good — they probably won’t be the main thing. People will still want to see some level of depth and expertise.
— Europe context
You’re in Berlin this week. European teams tend to build under different constraints with GDPR, tighter capital, users with higher privacy expectations. When you look at how product teams here design and build, what do you notice? And if ‘build for Europe first’ had been your starting constraint, what would you have done differently?
BRIAN: Well, there are the legal constraints. But I think a lot of the legal constraints are founded on good ideas, we should take care of people’s data, we should give people control over their data, the ability to delete an account, those kinds of things. So I don’t know that it’s just legally required to ship a product in Europe. It’s a good principle to have for anyone building software.
Everyone I’ve met so far, it’s pretty remarkable, we’re all thinking about the same things and solving the same problems. It’s not like we’re building different kinds of software. We’re all trying to solve real problems for real people, trying to figure out how to incorporate AI. What is this new tool going to change about our process? About the way people want to interact with our tools? About the way tools look? Are we all just going to be chatting with every app in the future? Probably not, but somewhere between that and our current state, it’ll be in the middle.
Everyone is trying to figure out the same things. How do we leverage AI without spending too much money? How do we incorporate the right blend of LLMs, non-deterministic outputs, code, and deterministic outputs? How do we work those things together to automate a process that deserves to be automated, or get insights that were hard to get in the past? These are all pretty universal things. I don’t know if that’s surprising, but it’s been consistent. That’s the cool thing about working at Notion, we get to build for people here and around the world. Most of our users are outside of the US, so this is just baked into how we ship software.
We hope you found Brian’s words as insightful as we did. A big thank you to Brian for his time, and to the teams at Notion and Laika Communications for making the introduction.
— The Ampli Team
Ampli is a media platform and community for the people building, designing, and running Berlin’s tech scene. We curate jobs, events, high-signal reads, and news — and amplify the voices of our community.
What kind of content would you like to see more of? Founder stories, guest posts, education, events, something else entirely? Let us know, we’re at connect@ampli.xyz.
