Your Product Is a Projection.
This is not a talk about AI. It is a talk about how product development is the same.
First, a little about me. My name is Ryan Allred. I’ve worked for startups my whole career, and more specifically, leading frontend teams for over 10 years.
In that time I’ve come to think of product development as a projection of different outputs from a variety of sources. Let me explain.
The job of most JavaScript developers is to build the user experience. This puts us in a unique position in the development process where we must also understand the problem space.
If you’re doing frontend development and you’re not involved in product discovery, you’re doing it wrong.
As the product builder, you are ultimately responsible for creating the final product a user actually uses.
The other inputs are useful. They are not the product.
Let’s imagine product development like a projector.
The product is what everyone actually wants, and why they came in the first place. It’s the end goal.
Nobody cares about the projector, they care about the projection. But you as an engineer build the projector.
If you could see inside this product projector, you’d see that it has several inputs. For the sake of the analogy, we’ll call these slides.
The slides are not the product. They help formulate the image, but they are not the image.
This is the part I actually want to talk about.
You can combine several ideas with AI and form an output quickly. Then you look at it. Then you change the mix and do it again. Rinse and repeat.
The product you make is a derivative of your inputs. If the inputs are wrong, the product is wrong. AI just lets you see that faster.
In practice it looks like this:
The first version is almost never the product. It’s just the first projection.
Inputs look like this:
If the only input is a ticket, you’re going to get a ticket-shaped product.
The more the inputs are treated like the end product, the more you’d end up becoming a ticket factory.
Every organization I’m aware of that builds products with a ticket factory has failed or changed their process, and the reason is simple: engineers need to think strategically about the product.
The solution, in my opinion, is to do real engineering. Engineering owns the final design, implementation, and maintenance of the product.
Why I think this is more important than ever: vibe coding. I love vibe coding. It’s great.
I have however looked under the hood of apps vibe coded by technical people and apps vibe coded by less technical people.
Apps vibe coded by technical people are largely production ready. Apps vibe coded by non-technical people are demo ready. And that’s okay.
Vibe coded apps are basically the same as Figma files. Not ready for production, but ready for projection.
This is where I need a real example from work.
One screen. A few inputs. The first output. What was wrong. Which input I changed. What it looked like the second time.
Your role as a frontend developer is getting new and extremely powerful tools with AI, but the end goal hasn’t changed.
The job is not typing faster. The job is choosing the inputs and deciding when the projection is actually the product.
The product is the projection. The slides are not.
Combine a few ideas, look at what you got, change the mix, and do it again.