Product thinking
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.
In my own work with agentic development, I can move from a rough idea to working software with less implementation effort than before.
That speed is useful. It has also made me look more closely at which parts of product development are actually changing.
My current read is that product development was never just about coding. Turning requirements into screens, tables, APIs, and workflows is only one part of the work.
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
Implementation speed is one constraint in product development. Faster tooling can make it cheaper to test an idea, but it does not decide which problem is worth solving or how the product will reach people.
Problem choice, distribution, workflow fit, trust, and adoption remain separate constraints. I saw that clearly at SilkStart: building the system was only part of helping customers move from familiar processes to a new way of working.
The practical questions included:
- 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.
Faster implementation does not remove that customer-facing work.
Cheaper implementation shifts where teams spend attention
As implementation gets cheaper, more attention can move to problem choice, workflow change, support, and trust.
That attention is practical: staying close enough to customers to understand where a workflow feels risky, what makes adoption difficult, and what support helps the change hold.
More prototypes can make judgment more important, because teams still have to decide which problems are worth solving and which changes people will accept.
Some of the questions I would want to keep visible are:
"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.
What faster implementation does not settle
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.
My current read is that faster implementation changes the balance of product work. Teams can test some ideas sooner and with less implementation effort.
It does not remove customer understanding, distribution, workflow fit, support, adoption, or trust. Those constraints still shape whether a product becomes useful.
That is what SilkStart continues to remind me: shipping the software and helping people change how they work are related, but they are not the same job.