Lately I have been thinking a lot about product building.
Not discovery alone, not design alone, not implementation alone. The whole thing, end to end.
For a long time, the hardest part was building the thing. Or at least that is how most of us experienced it. Writing the code, wiring the backend, dealing with infrastructure, dealing with limitations, dealing with time. Even when teams had good ideas, it still took a lot of effort to turn them into something real.
That is no longer the world we live in.
Today, with the tools we have, we can move much faster in almost every part of the process. We can explore ideas faster, prototype faster, write code faster, ship faster.
And yet, the overall process still feels slow.
The work itself is not slow. The system around the work is still static.
A feature gets discussed. Then researched. Then designed. Then built. Then someone has to update the documentation. Someone has to explain it to support. Someone has to tell sales what changed. Someone has to write internal notes. Someone has to capture screenshots. Someone has to prepare release notes. Someone has to make sure the rest of the company even knows the thing exists.
The feature is done, but it is not really done.
That is the part I keep thinking about.
The problem is not only building
A lot of teams can now build much more than they can comfortably absorb.
That is the strange part of the moment we are in.
We talk a lot about faster engineering, faster prototyping, faster delivery. But very little about what happens after that. What happens when the pace of change increases, but the rest of the organization still depends on manual handoffs, repeated explanations, scattered Slack messages, half-written tickets, and somebody remembering to update the help center.
We are getting better at producing change than at carrying that change through the company.
I think that is becoming one of the more important problems in product work.
Because the feature is not only the feature. The feature is also the explanation. The support context. The screenshots. The documentation. The changelog. The internal rollout. The sales context. The marketing context. The “what changed, why did it change, and who needs to care” part.
That work is usually treated as something that happens later.
I think that is wrong.
What I am interested in now
What interests me now is not only how to use AI to build faster. That part is already obvious.
What interests me more is whether we can use these tools to make the whole product process less static. Not only the coding part, but everything around it.
Can an idea become a better brief faster? Can design feedback become a useful decision log instead of disappearing into meetings and chat threads? And once something ships, can the explanation of that change be generated as part of the same flow instead of becoming a separate manual project?
That is the kind of system I have been thinking about. A system where one product change can move through ideation, discovery, design, engineering, documentation, and internal communication without being recreated from scratch every time it moves from one person to the next.
Because if you think about it, that is what a lot of this friction really is. Re-creation. The same feature gets re-explained again and again, in different words, for different people, in different tools, at different times.
That is expensive. It is slow. And at this point, it feels unnecessary.
One change, many outputs
If AI is useful for anything here, it is translation.
One rough idea can become a better-defined problem statement. One feature brief can become engineering tasks. One set of design decisions can become implementation notes. One shipped change can become a draft for documentation, a support update, a changelog entry, and an internal announcement.
The underlying thing is still the same. What changes is the audience.
Engineering needs one version. Support needs another. Sales needs another. But those versions should come from the same source of truth. They should not be invented independently by five different people trying to reconstruct what happened.
That is the part I want to improve. I want a process where the work carries its own context forward. Not perfectly. Not without human judgment. But much better than it does now.
What I would like product building to look like
The way I think about it right now is simple.
Every meaningful feature should have one living artifact behind it.
At the beginning, it is just an idea. Then it becomes a clearer problem. Then a proposal. Then it accumulates research, design references, tradeoffs, decisions, open questions, technical notes, rollout implications, and eventually the actual implementation.
By the time the feature ships, that same artifact should already contain most of what the rest of the company needs in order to understand the change.
Then AI can help transform that into the right outputs. A docs draft. A changelog entry. A support summary. An internal post. Maybe screenshots too. Maybe a short explanation for sales or a cleaner summary for leadership.
Not because humans should disappear from the process. Humans still need to review things, decide what matters, exercise judgment. But humans should stop starting from zero every single time.
That is the key thing for me.
I am not interested in blind automation. I do not want random generated text being pushed to customers or posted internally without anybody thinking. But I do think we should start building systems where the explanation grows with the work.
Instead of “we built it, now let’s explain it,” I want the explanation to get built as the work happens.
That feels much closer to the kind of process our tools should enable.
Why this matters
This is not only about speed.
Speed is nice, obviously. But the deeper value is reducing the cost of change.
A lot of good product improvements are not blocked because they are impossible to build. They get slowed down because every change creates a tail around it. Docs need updating. Other teams need context. Internal communication needs to happen. Screenshots need to change. Support needs to understand what customers will see.
That tail is real work.
And if we want teams to become more autonomous, then this is part of the problem too. Autonomy is not only the ability to write and ship code. A team that is actually autonomous can move without creating confusion around itself. The rest of the company can keep up with the product as it changes.
That is where AI becomes interesting to me. Not only as a coding tool, but as something that connects the stages of product work. From ideation through discovery, design, implementation, documentation, and internal rollout. One connected flow instead of a series of disconnected retellings.
The direction I want to explore
I do not have a final answer here. I am still working through what this should look like in practice. What should be automated, what should stay manual, what should be reviewed, what should be generated, what should be captured early so that the rest becomes easier later.
But I am pretty convinced about the direction.
We should stop thinking about AI only as something that helps us type faster. The more interesting opportunity is building a product process that does not go static the moment a feature leaves engineering.
A process where the feature does not stop at implementation.
A process where the feature carries its own explanation.