Product thinking / 6 min read
Product Development Was Never Just About Coding
Agentic development compresses software creation, but it does not compress trust, customer understanding, onboarding, workflow change, or adoption.
Since agentic development became popular, I keep hearing a version of the same assumption:
If everyone can now vibe-code an app, then product development must be getting easy.
I think that misses what product development has always been.
Product development was never just about coding. It was never only the work of turning requirements into screens, tables, APIs, and workflows.
It was also the work of helping people understand why a new way of working is better, why it is safe, why it is worth the switching cost, and why they should trust you when their own work is on the line.
The app can appear faster.
Prototypes, internal tools, workflow apps, and first drafts can move from idea to interface with much less engineering drag.
The product still has to be adopted.
Customers need a reason to switch, a path to confidence, and enough support to believe the new workflow will actually work.
Coding was only one part of the work
The mistake is assuming that the speed of coding was ever the main reason a product or business succeeded.
It wasn't.
Amazon did not win because it could write code faster than everyone else.
Microsoft did not win because it had the highest typing velocity.
Google did not win because the first version of the search box was hard to implement.
Code matters. Engineering quality matters. But the hardest parts of product development have usually lived outside the editor.
They live in questions like:
- Who is the customer?
- What problem is painful enough that they will change behavior?
- How do we reach them?
- Why should they trust us?
- How does this fit into their workflow, team, budget, procurement process, compliance model, and emotional reality?
- What makes them feel safe enough to adopt something new?
I learned this at SilkStart
I learned this in a very practical way during my SilkStart days.
SilkStart was SaaS for non-profits. We helped associations and mission-driven organizations manage membership, online payments, events, and websites. On paper, that sounds like software: membership records, payment flows, event pages, email lists, admin tools.
In reality, a lot of the product work was helping customers understand why this online version of their operations was better than the on-premise software, spreadsheets, paper forms, faxed renewals, and disconnected website workflows they already knew.
We had to explain why online payments could lead to more membership renewals than offline fax or mail-in processes. We had to show why a website integrated with member activity could help them understand their community better, serve members better, and continue their mission with more confidence.
None of that was easy to convey to a non-technical person. And it was not enough to say, "the software can do it." The customer had to see how the new workflow connected to the work they cared about.
Onboarding was an emotional product surface
After a customer decided to switch, the real work did not end. It changed shape.
There was training. There were onboarding calls. There were moments where someone needed to know that they could call us, ask a basic question, or have someone onsite when the stakes felt high. That practical support mattered, but the emotional support mattered just as much.
In B2B especially, adopting software is rarely just a feature decision. It is a trust decision. Someone is putting their operations, their member relationships, their payments, and sometimes their own professional credibility into a new system.
A good product team has to be there for that. It has to explain. It has to listen. It has to reassure. It has to understand when the blocker is not a missing button but a person who is afraid of breaking a workflow that their organization depends on.
- The account is configured.
- The data is migrated.
- The payment and event flows are enabled.
- The website integration is technically live.
- The team understands the new workflow.
- Staff know who to call when they feel stuck.
- Leaders can explain the change to members.
- The organization feels safe enough to rely on it.
The best product moments were human
Some of the strongest memories from that period were not about shipping a feature.
They were the moments after a deployment succeeded. The moments when a customer saw renewals come in more smoothly, events run better, member activity become more visible, or their organization grow because the system finally supported the way they wanted to serve people.
We celebrated those wins together. There were happy faces. There were overflowing thank-you letters. There was the feeling that the customer had not just bought software, but had made a difficult transition and come out stronger on the other side.
None of that is replaceable by agentic coding.
Product and Design matter more, not less
This is why I think Product and Design become more important in the agentic era, not less.
When code becomes cheaper, care becomes more valuable.
Not care as sentimentality. Care as the discipline of staying close enough to customers to feel the fear, optimism, pain, and joy on the other side of a product decision.
When prototypes become abundant, judgment becomes more valuable because it has to be grounded in that human connection.
When anyone can generate an app, the hard question shifts from "Can we build it?" to:
"Should this exist?"
"Who is it really for?"
"What human fear does it need to overcome?"
"What pain or hope is it meeting?"
"What workflow does it need to respect?"
"What trust does it need to earn?"
"What does good actually look like?"
Staying close enough to feel the customer's fear, optimism, pain, and joy.
Deciding which generated possibilities should become real products.
Being present when training, migration, and behavior change feel risky.
Making the product legible enough that humans feel safe adopting it.
Agentic development changes the supply side
Agentic development changes the supply side of software. It makes creation faster, cheaper, and more accessible.
But it does not automatically solve the demand side.
It does not automatically create customer insight.
It does not automatically create distribution.
It does not automatically create onboarding.
It does not automatically create trust.
It does not automatically make people want to change how they work.
The question is what still needs a human
So when people ask what agentic development means for software companies, I do not think the most useful framing is whether a category is dead.
The better question is: what part of product development remains after coding gets cheaper?
My answer is: a lot.
The customer still has to be understood. The value still has to be explained. The workflow still has to fit. The change still has to be supported. The trust still has to be earned.
If a product only existed because software was hard to write, it may be in trouble. But products that understand customers, reduce fear, fit into real workflows, and help people become better at their work still have a deep reason to exist.
The next generation of products will not win simply because they were coded faster.
They will win because they understand people better.
They will win because they combine agentic capability with human-centered product development.
In the agentic era, the bottleneck is not code.
The bottleneck is trust, adoption, and human change.
And that makes product development more human, not less.