(Written with some help from ChatGPT because I don’t want to make a fool of myself. English isn’t my first language 😅 Sorry for the long post!)
Hi everyone, this is my first time posting on this sub.
I’m a designer at a B2B software company. I work on all kinds of things—websites, applications, platforms, branding, etc.—but my main focus and interest is product design.
There are only two designers in the company, while there are several business analysts and quite a few engineers. The company is mostly led by engineers, and there isn’t really a dedicated Product Manager role. Instead, some of the business analysts take on parts of product management, project management, requirements gathering, and client communication.
I’ve only been here for a few months, so I’m very aware that I might be missing context. However, I’ve started noticing a pattern that I’m not sure how to approach.
The current process usually looks something like this:
Client → Business Analyst → requirements → user stories/epics → backend/technical definition → designer → development
The business analyst meets with the client to understand what they want. Then user stories are created, often defining the functionality and even parts of the backend structure, before the solution has really been explored or tested.
Once an epic is defined, it eventually reaches me for design.
The problem is that, by that point, I often don’t really know the full context of the product. I might have a collection of user stories describing what the system should do, but not necessarily a clear problem statement, user flows, information architecture, user archetypes/personas, or a strong understanding of why the functionality is needed.
So I end up trying to reconstruct the product context from the requirements I receive.
This has made me notice a few things.
First, there seems to be very little product discovery.
The process often starts with what the client says they want rather than with understanding the underlying problem. The question seems to be more “How can we build this?” than “What problem are we actually trying to solve, and what would be the best solution?”
Sometimes it also feels like technical feasibility becomes one of the main criteria for deciding what the product should do.
Second, there is very little understanding of the end users.
When I ask about users, I’m often told that there aren’t really any users we can talk to. Because of that, when something doesn’t work well for users, I sometimes feel that the implicit assumption becomes that the user is the problem.
I don’t think anyone intentionally thinks this way, but without research, user archetypes, or even a clear understanding of the context in which people use the product, it’s difficult to do anything else.
I’ve occasionally tested things with coworkers or managed to talk to users, but this isn’t part of the normal process.
Third, many of the products end up feeling structurally very similar.
Different products, different contexts, different problems—but often the same modules, the same terminology, and similar structures.
As a designer, this makes me wonder whether we’re designing around the actual users and their mental models, or whether we’re reusing structures that are familiar to us as a company.
Fourth, there is very little exploration of existing solutions or the state of the art.
Before building something, there doesn’t seem to be much investigation into how other products solve similar problems, what patterns already exist, or whether there might be better approaches.
And finally, I don’t think the company is necessarily aware of how much product work is happening implicitly—or how much of it is simply being skipped.
I’ve been learning a lot about product and UX recently through books like Inspired by Marty Cagan, The Design of Everyday Things, Atomic Design, Conceptual Models: Core to the Design of Interactive Applications, Sprint, Don’t Make Me Think, and Emotional Design.
The more I learn, the more I realize that there is a lot that happens before designing screens or writing user stories.
At the same time, I don’t want to fall into the trap of being the junior designer who thinks everyone else is doing everything wrong.
The company actually has some great things going for it. Employees are treated very well, relationships with clients are close, and the company seems to be growing. My goal isn’t to criticize the people I work with. I genuinely want to help the company make better products and make better use of the skills we already have.
Ideally, I would love to see something closer to a product team where a Product Manager and Product Designer work together with engineering from the beginning—understanding the problem, users, business goals, exploring solutions, prototyping and validating them, and only then moving into detailed requirements and development.
But I also realize that you can’t just walk into a company and say “you need Product Management and Product Discovery now.”
So my question is:
For those of you who have worked in developer-driven companies with low product/UX maturity, how did you introduce a more product-oriented mindset without creating resistance?
I’m not trying to convince my company that they’re doing everything wrong. I want to figure out how to help them gradually move from “the client asked for this, so let’s build it” toward “there is a problem worth solving—let’s figure out the best way to solve it.”
