Product Principles Examples: The Few Rules That Decide What Your Product Never Builds

This guide is for founders and business owners about to start a software product with a team or software company they hire. A small product can’t beat a bigger one on features. It wins by being clearly better at one job for one kind of customer, and product principles are the few written rules that keep it there: what you build, and what you never build.

What are product principles? Examples in one minute

Quick answer: Product principles are three to five short rules that tell your team which option to pick when two good options compete. Published examples include Intercom’s “opinionated by default, flexible under the hood”, Linear’s “simple first, then powerful” and GOV.UK’s “do less”. A good principle rules something out. Write yours before the build, with whoever leads the technology.

Ask about CTO as a service →

What building without principles costs you

Without written principles, every feature request is judged on its own, and each one sounds reasonable: a settings page for one large customer, a report an investor asked for, a second app for a partner. The loudest voice decides, or the developer with the strongest preference. Scope grows, the launch moves, and the product slowly turns into a smaller copy of the market leader, with less money behind it. Principles don’t block good ideas. They make each idea earn its place against the one job your product exists to do.

Principles, vision, philosophy and design principles: what’s the difference?

These words get mixed up in pitch decks. Each one answers a different question:

	The question it answers	The shape of an example
Vision	Where is the product going?	“Every small clinic in the UAE takes bookings online”
Product philosophy	What do we believe about good software?	“Software should make the common choice for the user”
Product principles	Which option wins when two good ones compete?	“Defaults first; a setting only when many customers ask”
Design principles	How do screens look and behave?	“One main action per screen”
Engineering principles	How is it built and changed?	“Proven technology, even over new”
Company values	How do we treat people?	“Say early what we don’t know”

A product philosophy is the belief. Principles turn that belief into rules a team can apply in an ordinary planning meeting. Design principles sit underneath them and guide the UI/UX design work.

Product principles examples from companies that publish theirs

The words in quotes are each company’s own; the right-hand column is our reading of what the principle keeps out.

Company	The principle, in their words	What it keeps out
Basecamp (37signals)	“Start With No”	Building a request the first time someone asks. The first answer is “not now”, and a request that keeps coming back gets a closer look.
Basecamp (37signals)	“fixed time, variable scope”	Letting the work grow until it fits the estimate. The time is set first, and the scope is shaped to fit it.
Linear	“Simple first, then powerful”	A first screen full of options. Power arrives as the customer grows.
Intercom	“Opinionated by default, flexible under the hood”	A blank configuration screen. Defaults and templates come first; customisation sits behind them.
Gusto	“No Product Dead Ends”	A flow the customer can’t finish without calling support.
GOV.UK	“Do less”	Building what someone else already provides well.

Two things stand out. Each principle is short enough to say out loud in a meeting. And each one costs something: Intercom’s own post on its principle describes a data feature that was first too flexible for customers to adopt, so the team added opinionated defaults. A principle that never costs you a feature is a slogan.

What does “opinionated software” mean?

Opinionated software picks one good way to do a job and makes it the default, instead of asking every customer to configure their own. The idea goes back to 37signals’ book Getting Real, whose chapter “Make Opinionated Software” argues that good software takes sides rather than trying to please everyone. In a Figma interview, Linear’s co-founder describes designing for “one really good way of doing things”. Gusto lists “Be opinionated” among its five product principles.

For a startup, being opinionated is usually right: one segment and one workflow, done well. It isn’t right everywhere:

• Where customers truly differ, such as approval chains inside large companies, keep a strong default and add configuration only where the business really varies.
• Where the rule is the law, such as UAE VAT or e-invoicing, there is no opinion to hold. The product follows the rule from the first release.
• Where language is part of the job. If your customers are in the Gulf, “Arabic and English from the first release” is a principle, not a feature for later. Our guide to Arabic app development shows what adding it afterwards involves.

How to write your product principles: a fill-in template

1. Start from the customer and the job. If you haven’t yet, read what your competitors’ users complain about. Your principles should protect the thing you will do better.
2. List the arguments you know are coming. Settings or defaults? Web or app first? One customer type or several? Launch sooner, or launch more complete?
3. Write each one as “X, even over Y”. The “even over” part names what you give up. If nobody would ever argue for the opposite, it isn’t a principle: “easy to use” fails; “book without an account, even over collecting more data” passes.
4. Attach one decision to each. Name a real feature it lets in or keeps out. If you can’t, drop the principle.
5. Keep three to five, and review them after launch. Change a principle when evidence from real users says so, not when one request is loud.

Copy this and fill it in:

For [customer] who need to [job], our product is the one that [what you do better].

1. We choose [X], even over [Y]. It keeps out: [a feature or request].
2. We choose [X], even over [Y]. It keeps out: [a feature or request].
3. We choose [X], even over [Y]. It keeps out: [a feature or request].

Not now: [one to three things you won’t build yet].

We revisit these when: [the signal, such as the same request from several paying customers].

A worked example, for an imaginary booking app for small clinics in the UAE:

1. A patient books without creating an account, even over collecting more data.
2. Arabic and English from the first release, even over a longer feature list.
3. Clinic staff run the day from a phone, even over a full desktop dashboard.
4. We connect to what clinics already use, even over replacing it.

Not now: medical records, in-app chat with doctors, a loyalty scheme.

How principles settle scope arguments with your team or vendor

This is where principles pay for themselves. Most scope arguments between a founder and a software company are two good ideas competing, with no rule to choose between them. Written principles turn the argument into a quick check.

The argument	Without a principle	With a principle
A large prospect wants a custom feature before signing	You build it, and now maintain two versions of the product	“One product for every customer”: offer the closest existing workflow, or log the request under “not now”
“Add a setting so each customer can choose”	Every new option multiplies the cases to test	“Defaults first”: ship one good default, and add the setting when the same request keeps coming back
The launch date is slipping	The date moves, then moves again	“Fixed date, flexible scope”: cut features to keep the date, and never cut correctness (what never to cut)
A rare case needs its own admin screen	A screen used a few times a year gets built, tested and maintained	“Manual first for rare cases”: your team handles it by hand until it repeats
A developer wants to move to a newer framework	The roadmap stalls while the code changes	“Proven technology, even over new”: a rewrite needs a customer reason
An advisor asks for an AI feature	It joins the roadmap because it sounds current	“Every feature serves the core job”: it waits under “not now” until it does

Put every change request through four questions: which principle does it serve, which does it break, what leaves the release to make room, and who decides? On our projects, the CTO recommends, the product owner reorders the backlog, and you make the call. The principles make that call quick, and the reason gets written down.

What this means for you: before you sign with any software company, give them your principles together with the brief. A vendor that pushes back on a principle early is useful to you. A vendor that agrees to every request will let the scope grow until the launch date moves.

Got a feature list that keeps growing? Tell us where your product is today and the customer you’re building for. We say what technical leadership you need now and what can wait. Ask about CTO as a service →

Not ready to talk yet? Ask for our company profile and we’ll send it to you.

Why setting principles is part of a CTO’s job

Many product choices are technical commitments in disguise. A settings page multiplies what has to be tested. A custom version for one customer splits the code. “Works offline” changes the architecture. That is why principles belong with whoever leads the technology, working with the founder, rather than with the developer who happens to be building that week.

As part of CTO as a service, we draft the principles with you before the build, use them to review scope with your developers or ours, and keep a written log of each decision and the principle behind it. You keep the final say. The same thinking shapes how you choose a first release in MVP vs MMP vs MLP, and how a good team says no in KISS and YAGNI for founders. If you’re weighing a fixed project against a product that keeps improving, read product mindset vs project mindset.

Qargo is a car rental and ride-hailing platform in Qatar, and we led its technical direction and architecture. Talk to the team that built it: book a meeting.

Write your principles before the first line of code

Since 2014 we have built software for more than 100 clients across the UAE, Saudi Arabia, Qatar, Kuwait, the USA and Canada. We are a software development company in Dubai, headquartered at Dubai Digital Park in Dubai Silicon Oasis, and the four ways to work with us show who runs the day-to-day work in each case.

Ask about CTO as a service → Tell us where your product is today and what you want it to be best at. We say what technical leadership you need now and what can wait. We reply by email first and set up a call only if you want one. Asking commits you to nothing, and we sign an NDA first if you ask.