Writing
Why ‘Why Now?’ Matters More When Software Gets Cheap
AI-assisted development makes it easier than ever to turn an idea into working software. That makes choosing the right problems—not merely building solutions—the harder and more valuable product skill.
It has become surprisingly cheap to turn an idea into software.
A PM can describe a workflow in the morning and have a convincing prototype by the afternoon. An engineer can test three approaches before committing to one. A designer can put something interactive in front of a customer instead of asking them to imagine it from a set of static screens.
This is mostly a very good thing. I’m using these tools constantly, and the faster feedback is hard to give up once you get used to it.
But cheap implementation has a second-order effect: weak ideas are now easier to justify.
For a long time, “Can we build this?” acted as a useful filter. Engineering capacity was limited, implementation was expensive, and even a small feature needed enough support to earn a place in the queue. That filter was imperfect, but it forced a certain amount of discipline.
Now a feature can look real before anyone has established whether it matters.
You can click through it. You can show it in a meeting. The happy path works. Once an idea reaches that state, it starts to feel inevitable. The conversation quietly shifts from “Should we do this?” to “What would it take to ship?”
That is why I think one product question is becoming more valuable: Why now?
“We can” is not a reason
“Why now?” does not need to produce a giant business case or a six-week discovery project. Usually, a few sentences and one or two useful pieces of evidence are enough.
Maybe a recurring user problem is getting worse. Customers might be asking for the same capability without being prompted. Usage data may show a meaningful drop-off in an important workflow. A technical breakthrough may have made a previously impractical solution possible. A competitor may have reset customer expectations. Another product investment may have created an opportunity that did not exist six months ago.
Any of those can be a good answer. The important thing is having an answer that separates these two statements:
We can build this.
This is one of the things we should spend attention on right now.
Those are not the same thing, even when building the first version only takes a day.
Building is cheaper. Owning is not.
The cost of generating code is only one part of the cost of a product decision.
Every feature asks something from the people who use it. It adds another choice, another path, or another concept they have to understand. It creates something the team has to maintain, support, document, measure, and eventually improve or remove. It competes with other work for organizational attention.
AI can reduce the effort required to create the first version. It does not make user attention unlimited. It does not remove product complexity. It does not automatically create an owner who will care for the feature after the excitement of the demo wears off.
That changes where the constraint lives. Implementation capacity is becoming less scarce in many parts of product development. Focus, confidence, and ownership are not.
Product reasoning should get lighter and sharper
I don’t think the answer is more process. Faster implementation should not be met with longer templates, more approval steps, or enormous PRDs designed to slow everyone back down.
The opposite is closer to the point.
If a team can prototype an idea in hours, the reasoning that precedes it should be lightweight enough to keep pace. A short note can often do the job:
- What problem are we seeing?
- Why does it matter now?
- What evidence gives us confidence?
- What do we expect to learn or change?
That is enough to make the bet visible without pretending certainty exists. It also gives the prototype a job. Instead of being a polished argument for shipping, it becomes a fast way to test the reasoning behind the idea.
This is the distinction I want teams to protect. Speed should increase the number of things we can explore, not the number of things we blindly ship.
AI gives us more optionality. We can try more approaches, communicate ideas more clearly, and get evidence earlier than we could before. The goal is not to turn every option into permanent product surface area. It is to become better at deciding which options deserve to survive.
When software is expensive, feasibility does some of your prioritization for you. When software gets cheap, you have to get much better at doing that prioritization yourself.
Why I’m writing this now
I’ve been thinking a lot about how quickly we can move with software today. The software development lifecycle is changing in real time, and I’m still working through what that means for how product teams explore ideas, make decisions, and ship responsibly.
Writing about it gives me a reason to step back from the tools and the day-to-day excitement and think more carefully about the larger shift. I don’t expect to have every answer, but putting these observations into words helps me sharpen them. And if other people are wrestling with the same questions, why not share what I’m learning along the way?