From pixels to proposals. How running my own product company changed the way I see design, stakeholders, and the future of our field.
A few years ago, I wrote about what it was like joining a startup as a solo UX/UI designer. I talked about wearing many hats, fighting for UX buy-in, and learning to let go of the idea of “perfect design.” Back then, I thought I was already stretching beyond a traditional design role.
I had no idea how much wider my lens was about to get.
Since that article, I worked with several product teams and organizations. I co-founded and ran Base87 Technologies, it’s a design and software development company where, over time, my title shifted from “designer” to “Product Lead”. I wasn’t just designing interfaces anymore. I was scoping projects, writing proposals, managing stakeholder expectations, and deciding when to say yes – and more importantly, when to say no.
As I reflect on where I’ve been and where the industry is headed, I find myself in an interesting position. The product design world has changed. The lines between designer, product manager, strategist, and even business developer are blurrier than ever. And after years of living in that blur, I’ve realized something: It’s not a bug. It’s the job.
Here are the lessons I learned when my role expanded beyond the screen – and why I believe the future belongs to product people who can operate in that gray area.
Understanding the Real Goal (Hint: It’s Not the Deliverable)
When you’re a designer embedded in a team, your brief is usually clear: design this feature, improve this flow, make this more usable. But when you’re the one sitting across from the client, you realize something fast — what they ask for is rarely what they actually need. But even back when I was working fulltime as a designer — I found myself asking a question that wasn’t technically in my job description:
“What is the real goal here?”
Here’s the thing no one really talks about: sometimes there’s no product manager in the room actually thinking about prioritization. Features get pushed to designers because a PM wants them, or because leadership asked for them, or because it sounded good in a meeting. But rarely does someone really ask — does this actually matter? Does it move the needle? Is this the right thing to build right now?
I started asking those questions. Not to be difficult, but because I couldn’t do good design work without knowing what we were actually trying to achieve. Sometimes the goal was more conversions. Sometimes it was reducing support tickets. Sometimes the stakeholder didn’t even know yet — they just knew something wasn’t working.
Often, I found myself acting as a stand‑in product lead before I even realized what that role entailed. I was connecting dots no one had been assigned to connect. When I moved to Base87 Technologies, that unofficial role became my actual job. My title changed — but the work had always been the same. I wasn’t just executing briefs anymore. I was helping write them.
Thinking for the Stakeholder, Not Just Designing for the User
While training or working with product design teams, we talk a lot about the user. Empathy maps, user journeys, personas. And I still believe in all of that.
But when you’re running a product company, you develop another kind of empathy – stakeholder empathy.
I had to learn to think for my clients. What’s practical for their budget? What’s realistic given their internal constraints? What will their boss actually sign off on? A beautiful, user-centered solution means nothing if it never ships because the stakeholder can’t champion it internally. I learned this the hard way — an actual client had this situation, and the project is still on-hold to this day. But that’s a story for another time.
One of the most valuable skills I developed was the ability to translate between worlds – between what users need, what the business wants, and what the technology can actually do. That translation layer? That’s where product people live. And it’s becoming more important than ever.
The Art of Scoping (Or: Why “Yes” Is Easy and “No” Is Strategic)
Here’s something no one teaches you in design school: projects can’t go on forever. And scope can’t shift every week. Not if you want to stay in business. Not if you want to keep your team sane.
At Base87 Technologies, I became the person who had to say: “That’s a great idea. Let’s put it in Phase 2.” Or sometimes: “We could build that, but here’s why I don’t think you need it right now – and here’s what I think we should do instead.”
Saying no is hard. Saying no and explaining why is a skill. When you do it well, clients don’t feel dismissed – they feel like you have their back. They start trusting you not just as a vendor, but as a strategic partner.
The best product people I know aren’t the ones who say yes to everything. They’re the ones who know which yeses actually matter.
Dropping the Jargon (Or: How to Actually Be Understood)
This one was humbling.
I remember using terms like “information architecture,” “heuristic evaluation,” and “user flows” in client meetings. Sometimes I’d later find out the client had no idea what I meant but was too embarrassed to ask.
I had to learn to adapt. Not dumb things down – translate. Different clients work in different domains, come from different age groups, and have different mental models. A marketing director and a nonprofit program manager don’t speak the same language, and neither of them speaks fluent “design.”
The goal isn’t to sound smart. The goal is to be on the same page.
When I started explaining concepts through metaphors my clients actually understood, a lot changed. Meetings became shorter. Decisions became faster. Trust became deeper.
As I mentioned once, Jared Spool said: “Anytime someone on your team starts talking about making things consistent, change the conversation to be about what the users’ current knowledge is.” I’d extend that: anytime you catch yourself using insider language, change the conversation to match your audience’s current knowledge.
When to Be Flexible (Without Being a Pushover)
This is the tightrope every product person walks.
Clients change their minds. Budgets shift. Timelines compress. Sometimes the brief you signed off on in January looks nothing like reality in June. I learned that being rigid doesn’t earn you respect – but being a pushover doesn’t either.
The sweet spot is negotiation with empathy.
When a client needed to pivot, I didn’t just say “that number of new pages will cost extra” or “that’s not in scope.” I asked what changed, why it mattered, and what we were really trying to solve. Sometimes we’d adjust the scope. Sometimes I’d push back and propose a different approach. Sometimes we’d find a middle ground that nobody had considered.
What I wanted clients to see wasn’t someone who was easy to push around. It was someone who cared enough to ask hard questions, who thought strategically about trade-offs, and who was flexible in service of the outcome – not just the process.
That’s the kind of product person I want to be known as.
AI Changed Everything (And I Had to Learn to Explain It)
Like a lot of people in tech, I’ve spent the last couple of years deep in AI – not just using it, but understanding how it works, what it’s good at, and where it falls short. At Base87 Technologies, we built AI-powered tools like Dayline Observer (an AI tool that auto‑digests daily updates in Hong Kong), etc.
Here’s the thing about AI: everyone wants it, few people understand it, and even fewer can explain it in a way that makes someone feel confident rather than anxious.
I became the explainer. I’d walk clients through what a language model actually does, why “AI” isn’t a magic button, and how to think about features that genuinely help users versus features that just sound impressive in a pitch deck. I’d show them what was possible, be honest about what wasn’t, and help them see where AI could actually move the needle for their business.
In a world where every company is becoming an AI company, the ability to translate between technical capability and human need isn’t optional anymore. It’s the job.
The Follow-Up Is Part of the Product
One subtle shift I noticed when I moved into a product lead role: the work doesn’t end when the design is delivered. Or when the proposal is sent. Or even when the product ships.
How you follow up matters. Are you checking in because you care about the outcome, or because you’re chasing the next invoice? Clients can feel the difference.
I started thinking of follow-ups as part of the product experience. A thoughtful check-in after launch. A quick note when I saw something relevant to their business. Transparency when things didn’t go as planned. These small moments built relationships that lasted longer than any single project.
Product thinking isn’t limited to the thing you build. It’s in every touchpoint.
Where the Lines Are Heading
If I look at where the product industry is going, I think the blurring I experienced isn’t unique – it’s just early.
More designers are being asked to think about business strategy. More PMs are being asked to understand design systems. More founders are realizing they need someone who can speak all these languages at once.
The job posting of the future won’t say “UX/UI Designer” or “Product Manager” or “Business Analyst” as cleanly as it used to. It’ll say something like: “Someone who can understand a problem, explore solutions, align stakeholders, scope realistically, and ship something that works – while keeping humans at the center of it all.”
That person might come from a design background. Or engineering. Or business. What matters isn’t the label they started with. It’s whether they can operate in the blur.
Finding Your Own Shape in the Blur
If there’s one thing I’d leave you with, it’s this: don’t wait for a title to tell you who you’re allowed to be.
I started as a UX/UI designer asking questions I wasn’t “supposed” to ask. I ended up running a company where asking those questions became my entire job. The throughline wasn’t a promotion or a rebrand — it was a way of working. Staying curious about the goal behind the request. Translating between people who don’t speak the same language. Knowing when to push back and when to bend and caring about the outcome.
The industry will keep blurring. New tools will emerge, new titles will be invented, and the lines between design, product, strategy, and operations will keep shifting. That’s not something to resist. It’s something to move with.
I’m still very much hands-on at Base87 Technologies — building products, working with clients, and exploring where AI and design thinking can solve problems that actually matter. I don’t have all the answers, but I’ve gotten comfortable operating in the space where things aren’t fully defined yet. That’s where the interesting work always seems to live.
Somewhere between the pixels and the roadmap, between the client call and the product decision, I found the work that actually fits. Not because I stopped being a designer. Because I finally let design be bigger than the screen. If you’re navigating your own blurry lines — or building something that sits right in the middle of them — I’d genuinely love to hear what you’re working on. The best conversations always start with someone willing to ask: ‘What is the real goal here?’
Thanks for reading! 💗
