AI tools have quietly removed the biggest excuse product teams used to have. A working prototype used to take months and a real budget. Now a small team can ship a functional version of almost any idea in days. That sounds like good news, and mostly it is. But it changes where the risk in a product actually sits.
When development was slow, a bad decision about who to build for or how to reach them cost you time you could still recover during the long build. Now that same bad decision shows up immediately, because the build is no longer the thing standing between you and the market. The two jobs that decide whether a product survives, product management and go-to-market, were always the harder work. They are just no longer hidden behind a long development runway.
Development Was Never the Only Bottleneck
For years, teams could point at engineering timelines to explain why a product was not out yet. That excuse is disappearing. AI-assisted coding, no-code tools, and reusable infrastructure mean a team can go from idea to working software far faster than before.
The bottleneck has moved upstream, to the questions that used to get asked casually and answered with assumptions: what exactly are we building, for whom, and why would they choose it over what they already do?
This is not a new problem. It is an old problem that used to be masked by slow production. Drew Houston, Dropbox’s founder, has said that before building out the full product, he put together a simple demo video showing how the product would work in practice. According to his own account, the beta waiting list jumped from around 5,000 to 75,000 people overnight after the video circulated.
This is a founder-reported figure, not an independently audited number. But the underlying lesson holds regardless of the exact count: he tested whether people wanted the experience before investing further in building it out. That sequencing, demonstrate first and build second, is exactly the kind of decision that AI-accelerated development makes easier to act on and easier to skip.
Scope the Smallest Valuable Product
Fast development tempts teams to build the full vision immediately, because for the first time it seems possible. Resist that.
The goal of an early build is not to be complete. It is to answer a specific question about a specific user. Buffer’s founder, Joel Gascoigne, has described starting with a two-page website before any product existed. One page explained the idea. The second collected email addresses. Once he saw interest, he added a pricing page to see whether people would actually commit to paying before building the scheduling tool itself.
This is a retrospective account from the founder, but the method is worth taking seriously. He separated the question of interest from the question of willingness to pay, then tested both before writing the product.
That separation is the core skill of scoping. A smallest valuable product is not a stripped-down version of your full idea. It is the smallest thing that can honestly test the riskiest assumption you are making, usually about the user’s problem or willingness to change behavior.
If you cannot articulate what assumption your first build is testing, you are not scoping. You are guessing with better tools.
Choose a Reachable Customer and a Real Channel
A product with no plan for reaching people is not a product. It is a demo.
Paul Graham’s account of early Airbnb describes the founders concentrating on New York and personally improving listing quality, including photographing hosts’ spaces themselves, rather than trying to grow everywhere at once.
The specific detail worth taking from this is narrow: they treated customer and supply quality as something to work on directly and locally before trying to scale. It does not prove that photography alone caused Airbnb’s growth.
The broader point is that picking one reachable segment and doing unscalable work there often teaches you more than a broad, thin launch.
Distribution decisions apply just as much to established SMEs launching digital products as they do to startups. An SME already has a channel: existing customers, existing trust, and existing sales relationships.
The mistake many innovation teams make is assuming that a distribution advantage means they do not need to ask who the digital product is really for.
Slack is a useful example. According to Slack’s SEC filing, the tool began as an internal communications system built by the team behind a game called Glitch. When Glitch was discontinued, the team recognised that they had built something else entirely, a tool worth offering to other organisations.
The technology did not change dramatically. What changed was the recognition of a different buyer with a different problem.
Innovation teams inside SMEs should ask that question early: is this the same product for our existing customers, or a genuinely different product for a different buyer?
Treat Pricing as Product Discovery
Pricing is often treated as the last decision before launch. It should be one of the first questions you test, because price tells you more about real demand than a survey.
OpenAI’s rollout of ChatGPT illustrates this without needing any adoption or revenue claims. ChatGPT launched in November 2022 as a free research preview. Three months later, OpenAI introduced ChatGPT Plus at $20 per month, offering priority access and faster responses.
Strong technical capability did not remove the need for a packaging and access decision. Someone still had to decide what was free, what was paid, and what the paid tier was actually worth to users.
That sequencing, free first to learn usage patterns and a paid tier later to test monetisation, is a go-to-market choice. It is not a technical decision.
The same applies to a new product inside an established company. Pricing affects positioning, adoption, sales incentives, support costs, and whether the product complements or threatens the existing business.
It is not a number to add at the end of the roadmap. It is part of the product definition.
Startups and SMEs Face the Same Questions
A first-time founder is testing whether a market exists at all. An SME launching a digital product is testing whether an existing market will behave differently online, and whether a new offering competes with or complements the core business.
Both need the same underlying discipline:
- Define the user narrowly.
- Test the smallest version of the value.
- Find one reachable channel.
- Price to learn rather than maximise on day one.
- Sequence decisions so each step reduces a meaningful risk.
The difference is that SMEs have more to protect. They carry existing revenue, brand trust, customer relationships, and internal politics. Their validation needs to account for cannibalisation and channel conflict in a way a pure startup does not.
That makes product management more important, not less. The job is not simply to prioritise features. It is to create enough clarity that the organisation can make a good bet without confusing internal enthusiasm for market demand.
A Practical Pre-Build Checklist
Before writing a line of code, however fast that code is now to write, a team should be able to answer these questions plainly:
Who exactly is the first user? Describe their role, context, and current behaviour.
What decision or behaviour are you trying to change?
What problem is important enough for them to change?
Where will the first 100 users come from? Name the channel, not just the audience.
What will they pay, and what have you done to test that before building the full product?
What is the smallest version that can answer these questions honestly?
What evidence would make you stop, change direction, or narrow the scope?
If any answer is vague, the fix is not to build faster. It is to slow down on these questions until they are not vague anymore.
The Work Did Not Disappear. It Moved.
Faster development is a genuine gift. It removes a real constraint that used to protect teams from their own unclear thinking, because slow builds gave everyone time to notice a bad direction before too much was spent.
That protection is gone now.
The upside is that teams who do the upstream work of scoping, customer selection, distribution, and pricing get to see the results of good decisions faster too. The teams that skip that work simply get to see their mistakes faster.
The hard part of building a product was never really the code. It was deciding what to build, for whom, how they would find it, and why they would pay for it.
That work is simply more visible now. There is nowhere left to hide it behind a long development timeline.
Sources
- Dropbox demo video and beta waitlist, founder account: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
- Buffer two-page site and pricing test, founder retrospective: https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/
- Airbnb early New York focus and listing quality, Paul Graham: https://paulgraham.com/airbnbs.html
- Slack origin as internal tool from the Glitch team, SEC S-1 filing: https://www.sec.gov/Archives/edgar/data/1764925/000119312519116993/d674028ds1.htm
- ChatGPT free research preview launch: https://openai.com/index/chatgpt/
- ChatGPT Plus pricing launch: https://openai.com/index/chatgpt-plus/