If AI can build software, what should you learn?
I believe the bottleneck has shifted from coding to thinking.
That does not mean engineering has become unimportant. It means more people can now reach the point where engineering begins—and the quality of what they create depends on decisions they may never have been taught to make.
As I argued in Everyone can build software now. Very few can build good software, AI lowered the barrier to execution. It also lowered the barrier to building the wrong thing.
The response is not to learn every discipline in exhaustive detail. It is to develop enough range to see the whole product, ask better questions, and know when deeper expertise is needed.
1. Product thinking: decide what deserves to exist
Product thinking turns a broad ambition into a specific problem, user, outcome, and sequence of choices.
PRDs, user stories, acceptance criteria, MVPs, prioritisation, and roadmaps are useful because they reduce ambiguity before development begins. But the document is not the skill. The skill is deciding what matters and making that decision testable.
A weak MVP is simply a smaller list of features. A strong MVP is the smallest credible way to learn whether the core promise is valuable.
Dropbox’s early product became widely understood through a simple demonstration of the experience before the full infrastructure was available at scale. The lesson is not that every founder needs a video. It is that evidence about the promise can come before a complete product.
The practical question is: What is the riskiest assumption, and what is the least expensive honest way to test it?
Companion draft: Product thinking before code.
2. Systems thinking: see beyond the screen
I often begin with a simple model: Input → Process → Output.
It applies to software, AI, and business. What enters the system? What transforms it? What should emerge? Then: who owns each step, what information is lost, where does judgment enter, and what happens when the normal path fails?
Take a ride-booking service. The customer sees a map, a car, and a price. The system also coordinates location, driver availability, matching, payments, safety, support, demand, and exceptions. Improving the button while ignoring the surrounding system can make the interface cleaner without making the service better.
This is why I prefer a decision system over another dashboard. A useful product does not merely display information. It helps the right decision move through the organisation.
Companion draft: Systems thinking for builders.
3. Human behaviour: design for the person under pressure
Users experience decisions, not architecture.
They do not care how elegant the component structure is if they cannot tell what to do next. They do not experience the database schema; they experience the moment a form rejects their input, a payment feels uncertain, or a warning arrives too late.
Duolingo’s streak is a familiar example. The underlying lesson is not “add gamification”. A streak makes continuity visible and gives a person a reason to protect behaviour they have already started. Used carelessly, the same mechanism can become noise or pressure.
Good behavioural design considers hierarchy, language, defaults, feedback, memory, motivation, and cognitive load together. It respects the user rather than trying to trick them into activity.
Companion draft: Designing for human behaviour.
4. Business thinking: understand the cost of the answer
A product can be useful and still be a poor business decision.
Builders need to think about buy versus build, feasibility, return on investment, maintenance, total cost of ownership, and opportunity cost. The first version is rarely the full cost. Data quality, security, support, integrations, model changes, and operational ownership continue long after launch.
This is especially important with AI. A compelling prototype can hide the ongoing work required to make its output reliable, governed, and useful in a real workflow.
Business thinking does not mean reducing every idea to immediate revenue. It means understanding what the organisation must continue to believe, fund, and operate for the product to remain worthwhile.
Companion draft: Business thinking before building.
5. Marketing and positioning: make the value legible
Products succeed when people can understand their value and recognise that the value is for them.
That is a product responsibility as much as a campaign responsibility. Positioning affects the audience you choose, the problem you lead with, the language inside the interface, the comparisons people make, and the moment at which the product proves itself.
Notion can support notes, documents, databases, projects, and many other uses. Its flexibility is a strength, but flexibility alone can be difficult to explain. Templates, use cases, and audience-specific examples help people recognise a starting point. The broader lesson is that a product may need range internally and clarity externally.
Builders should be able to answer: For whom is this most valuable, in what situation, and why is it a better choice than the current behaviour?
Companion draft: Marketing for builders.
6. AI orchestration: direct, constrain, and verify
Prompting is only one small part of building with AI.
The deeper capability is orchestration: giving an agent the right context, separating a large objective into inspectable tasks, documenting decisions, controlling access, testing the result, and recovering when the output is wrong.
Specification-driven development matters because AI is confident in the space left by ambiguity. Clear requirements, examples, constraints, and acceptance criteria do not eliminate mistakes. They make mistakes easier to detect.
Verification must also match consequence. A generated marketing experiment and a generated permissions system should not receive the same level of review.
Companion draft: Spec-driven development in the AI era.
Learn them as one connected practice
These six disciplines are not independent boxes.
Product thinking identifies the problem. Systems thinking reveals what the solution touches. Human behaviour shapes the experience. Business thinking tests whether it is worth sustaining. Marketing makes the value understandable. AI orchestration turns the decisions into a controlled process of execution and verification.
Remove one and the weakness appears elsewhere. A useful idea without positioning struggles to reach people. A clear proposition without operational thinking collapses under real use. A sophisticated agent without product judgment performs the wrong work more efficiently.
The modern builder is not the person who generates the most. It is the person who makes the strongest connected decisions.
Start with the next decision
You do not need to become a product manager, designer, strategist, marketer, and engineer at once.
Start with the product you are trying to build. Write down the user, the situation, the outcome, and the riskiest assumption. Map the inputs, process, and outputs. Identify what the person must understand. Estimate what the system will cost to operate. Explain the value in one clear sentence. Then give AI a specification you can actually verify.
The point is not to slow down the new speed of building. It is to give that speed direction.
AI lowered the barrier to building. The builders who matter will be the ones who learn how to choose, connect, and judge what gets built.