Products do not appear fully formed. They move through deliberate stages, and each stage exists to answer one question as cheaply as possible before more money is committed.
The three words people use most often are POC, prototype and MVP. They get used interchangeably in meetings, and they are not interchangeable at all.
Learning Objectives
After this lesson, you will be able to:
State the one question each of POC, prototype and MVP is built to answer
Recognise the cost of confusing them in either direction
Explain what makes a minimum viable product viable rather than merely small
Follow the pipeline from discovery through general availability to end of life
Discovery is the work of confirming the problem is real before anyone writes code to solve it.
It usually involves talking to the people who have the problem. Customer interviews, surveys, and looking at what competitors already do. Teams often size the opportunity, asking how many people have this problem and how many could realistically be reached.
Some common tools you will hear named. Personas are fictional archetype users, used to keep conversations concrete. User journey maps trace what someone actually does from start to finish, including the parts outside your product. The jobs-to-be-done framing says people do not buy products, they hire them to do a job. Understanding the job explains behaviour better than describing the person does.
What discovery should produce is a clearly stated problem, evidence that it matters, and some sense of what solving it is worth.
The question is whether something is technically possible.
A proof of concept is small, internal and deliberately rough. Can we read data out of that legacy system? Can a model extract these fields accurately enough to be useful? Can these two services talk to each other at all?
It has no interface worth looking at, it is not built to be maintained, and it should be thrown away afterwards. That is not a failure of discipline; it is the point. Code written to answer a question quickly is not code you want to keep.
The part teams most often skip is writing down what success means before starting. "Extracts at least 90% of the fields correctly from 100 sample documents" is a success criterion. "See if the model is any good" is not, and it produces a proof of concept that never quite ends.
A closely related idea is a spike: a time-boxed piece of research inside a sprint, where the deliverable is an answer rather than working software.
A prototype simulates the experience without building it. It is frequently made in a design tool with no real code at all: clickable screens that look real enough for someone to react to.
Fidelity varies deliberately. A paper sketch or wireframe shows layout only, and gets you feedback on structure without anyone commenting on colours. A mockup adds the full visual design. An interactive prototype lets someone click through a flow as though it worked.
The entire value is that changing it is cheap. Moving a button in a design file takes seconds. Moving it after it is built takes a ticket, a review, a test and a release.
What Do You Think?
A team spends three weeks building a polished, fully functional prototype with a real database behind it, then shows it to users, who say the whole flow is wrong. What went wrong with the process?
An MVP is the smallest genuinely working product that delivers the core value to early users and teaches you something true about demand. The term comes from the lean startup idea of building, measuring and learning in a loop, where the point of shipping is to find out something you could not have found out otherwise.
Two well-documented examples are worth knowing because they show how little you sometimes need to build.
Dropbox tested demand with a demonstration video before the product was finished, measuring how many people signed up on the strength of the idea alone. Zappos began with the founder photographing shoes in local shops and buying them at retail whenever an order came in. Neither had the automation their eventual product depended on. Both learned whether anyone wanted it, which was the only question that mattered at the time.
That second pattern has a name you will hear: a Wizard of Oz MVP, where humans do by hand what the product will eventually do automatically, and the user cannot tell.
A general availability release, often written GA or v1.0, is the point where the product is offered to everyone rather than a selected group. Before it you will usually meet alpha, meaning internal or very limited testing, and beta, meaning a wider group who know they are early and expect rough edges.
Growth and scale is where the work changes character. The questions stop being "does anyone want this" and become "does it hold up at ten times the load" and "what does it cost to run".
Maturity is when the product is established and most work is incremental. This is where a large share of industry employment actually sits, and it is rarely what job adverts describe.
Sunset or end of life is the deliberate retirement of a product, which involves migrating users off it, and is more work than people expect.
Quick Check1 / 3
A team must find out whether an AI model can extract invoice totals accurately enough to be worth building on. What should they build, and what should they decide first?
Proof of concept asks whether it can be built. Prototype asks whether it is the right thing. MVP asks whether anyone wants it.
Write down what success means before starting an experiment, or it will not have an ending.
Prototypes are valuable because they are cheap to change. Building them at production fidelity destroys the only advantage they have.
Minimum viable means the smallest complete journey, not a partial product. Each step should be usable on its own.
Alpha, beta and general availability describe how wide the audience is, not how good the software is.
Next: Tools of the Trade — the software teams use to track work, store code, ship releases and talk to each other, and what each category is actually for.