What product definition is
Every product embodies decisions, including how it fits with what people already use. Definition makes them deliberately, before the build makes them by accident.
A good definition is short enough to read in one sitting and specific enough to settle arguments. It usually covers:
- The problem. What’s broken, slow, missing or newly possible, in the words of the people who experience it.
- The audience. The primary users, and the people affected secondhand, like administrators, managers or partners.
- The core value. The one or two things the product must do exceptionally well.
- The first version. What’s in, what’s deliberately left out, and why.
- The boundaries. What the product won’t become, even later, so scope arguments end quickly.
- How we’ll know it’s working. Measures or signals agreed before launch.
Three levels of software
Software comes in three levels, each with its own standards:
- Prototype. Answers a question or settles a decision. Built for speed and often thrown away; nobody relies on it, though some get hardened into products.
- Tool. For a small, known group, like one team or workflow. It has to work, but polish and edge cases can wait. A tool can be the end state, or the step before production.
- Production. For people who depend on it. Needs reliability, security, access control, support and a long-term plan.
Expensive mistakes often come from building at the wrong level: gold-plating a prototype that should have been thrown away, or putting a quick tool into production without the reliability people need. Projects often climb the ladder on purpose: a prototype proves the idea, a tool shows real use, and production investment follows.
Build, buy or connect
Definition also asks whether to build at all. Being quick to build doesn’t make something worth building.
- Buy when what you need is a vendor’s whole product, like payroll, email or accounting. A company that does only that will outpace anything custom over time.
- Build when the software is your advantage, your workflow is specific to you, or nothing on the market fits how you work.
- Mix the two, often the best answer: buy the core systems, then build the connections and the thin layer of tools that fits them to your work. That layer often ends up holding your most useful data.
Disposable and seasonal software
Some software is built for one goal or one season, then retired: a tool for a single campaign, an event, a one-time data migration or a quarter-long initiative. AI-assisted development makes that cheap enough, if it’s designed to be thrown away: no over-engineering, a clear end date, and data you can take with you. Definition decides whether it should be permanent or temporary.
Starting from a hunch
Good ideas often arrive half-formed: a founder’s hunch, a team’s frustration, an opportunity a leader can see but can’t yet describe. That’s a good time to start; nobody should need a complete specification before seeing anything work.
We define just enough to build a first version, then let use shape the next decisions, including where scope should grow.
Defining AI products
Products that depend on AI need a few extra decisions:
- What does the AI do, exactly?
- What happens when it’s wrong?
- Where does a person review or approve?
- What data does it use, and who owns that data?
- How will its output be checked?
The answers shape the experience and the architecture, and they’re far easier to settle now than after launch.
How we write a definition
We start from what discovery taught us, draft quickly in plain language, and test the draft against a prototype early. A definition that sounds right on paper can feel wrong in use.
We’re direct about trade-offs: if a feature isn’t earning its place, or buying beats building, we’ll say so. The aim is a product that does a few things very well.
