The New Software Org
March 25, 2026 · 5 min read
The current org
A quick refresher on how current organizations generally work from my understanding.
- product people make ideas
- product people build acceptance criteria
- engineers theorize how to build idea
- negotiations
- a final PRD and ERD is signed off, work begins
This is super simplified, but the concept is you have an idea factory, then you move forward with the good ideas, then you build them. But a new contender has come to play...
Product needs to become more technical
AI (hooray!) is really good at making prototypes, but writes so much code, so quickly, and makes enough assumptions on nuance that its not quite ready for production lines at mass scale without a good amount of human intervention or understanding how to ensure it writes the correct stuff. But for prototyping, holy smokes. You can say "add a button to my website that takes you to a new page that flashes the background multiple colors" and in a moment you will probably get what you are looking for. And if you don't, in the next 5 minutes you can revert and try again.
Because prototyping is so fast an efficient, it means a product team, ideally, can make prototypes you can actually feel. Magic in software is a combination of the end user experience, and the genius of systems behind the screen. The end user experience should no longer be an idea in someones head that they should try to convey to others. An analogy here is artwork. A wicked strong artist is able to take exactly what is in their head, and make a real image that people can see. Of course there are levels of mastery like trying to evoke specific emotions, guiding eyes to specific points, etc, but the concept is I have an idea in my head, and I can put make it happen. Often, the barrier to this is the ability to use tools. A good painter is able to use a paint brush like its their own hand, a strong video editor knows exactly how to use a tool to make a transition feel smooth, and now, product teams have no excuse not to create a living prototype. Before, you would have to know how to code, and be a pretty strong and experienced engineer to quickly spin up a prototype for a feature. State management, languages, frameworks, etc, takes a lot, which is why a lot of teams use Figma to look at screens. But even Figma is run by UI/UX teams!
So what's my point? Now, a product team should be a prototype factory. They should be pumping out ideas like no-ones business. If I want a new feature, I want a prototype of it. And one prototype isn't enough, give me the same thing with different colors, different font sizes, different buttons, backgrounds, animations, make a bunch of em. When you finish with a prototype, combine it with others. Show a suite of new, interconnected features with test and sample data. This team should be a permanent hackathon team. Build, build, build. When you have something that looks shippable, test it. Get a testing crew, get super users, whatever it may be, get feedback. This cycle should take days, and after a year you should have an extremely interactive concept.
What happens after product?
The product and prototypes are built, felt, and agreed on. Now it's time to talk to engineers. At this point you need extremely technical people to build solutions. In the endless debate of "AI is going to take your job, AI is garbage, AI is so fast, AI is technical" you need to look at whats true and what is grey. Truthfully, there is no engineer on the planet that can code as fast as AI. I don't care what you claim, you cant write 13,000 lines of functional code in 4 hours. AI can. Is that code clean, strong, scalable, absolutely not. That's why its meant for prototypes. Something you can look at and throw away. For the engineering team, now you start designing work. An architect in this org should be constantly designing systems for prototypes. That's it. If an architect is out of systems to design, you need more product people. If there are too many prototypes to keep up with, hire another architect. That's the simplest loop here. You have one team making ideas, and another team theorizing their implementation. Once architects have built out their designs, engineers implement them. For now, I'm gonna go on a limb and say we have a couple years yet where we will need people reviewing everything. But AI is great at pattern recognition and replication, so its only a matter of time until your app, which moves data from one place to another and transforms it, will be pretty easy for AI to take over these parts. But at this moment in time, this is how an org will flourish. You are going to have people committing directly to main and quickly burying themselves in tech debt that they can't crawl out of, you are going to have people who refuse to innovate and get left behind, then you will have people that find the balance. This structure I have written is one way to strike this balance. But if you think you are going to spend the next 15 years in product asking questions, writing documents, and confusing people because everyone has a different picture of a feature in their head until UI finishes up, you are going to get left behind fast.