Using Your Own Product: The Cost and Return of Living With What You Sell

A team notices the gaps in a tool it uses every day within a few hours; it learns the gaps of a tool it does not use only when a customer complains. The difference is weeks, sometimes months — and throughout that time the gap quietly spoils the day of everyone who bought the product. The effect of using your own product on quality comes from a mechanism this simple: the feedback loop gets shorter.

Its second effect is on prioritisation. Viewed from a distance all gaps look equal, and the list gets ordered by whichever item was requested loudest. In a team that uses the product, the order forms itself: whatever annoys you most during the day rises to the top. That tends to be what annoys users most as well, because you are doing the same work on the same screens.

Let us also state its limit: you are not the typical user. Whoever wrote the product uses the screen with their eyes closed and cannot see where a newcomer hesitates. Your own use answers 'what is broken' well, but it cannot answer 'what is unclear'. For the second you have to watch a real user; the two do not substitute for each other.

Our content platform's own marketing site lives as a tenant on that platform. In other words the product's marketing page is managed by the product. From outside this looks like a pleasant detail; from inside it is the harshest quality check. If finding a field in the panel becomes harder, we are the first to feel it, because we edit our own copy there.

The same is true for our work tracking tool: we run our own tasks, bugs and releases in it. So the roadmap takes shape inside daily use rather than in a meeting room. The sentence 'that screen has three clicks too many' becomes a work item faster than a customer request — because those three clicks are annoying all of us that week.

We follow the same principle on our corporate site: the public face is written with one framework and the admin panel with another, and both speak the same interface. We applied the split we recommend to clients to ourselves first; so when asked 'why does this pairing make sense', we can answer not in theory but by pointing at the site you are browsing.

This approach should not be told romantically; it has a real cost. Using your own product means putting an immature tool into your workflow. You invent workarounds because of a missing feature, redo a task because of a bug, and sometimes drop your actual work to fix the product. Using a mature ready-made tool is, in the first year, almost always faster.

The second cost is blindness. A team that sees the same screen every day gets used to its oddities and after a while stops noticing them. The only way to counter that is bringing in an outside pair of eyes at regular intervals: asking someone who has never used the product to do a task while you watch. Your own use creates the blindness; user testing dissolves it.

Two things get confused: using the product for your real work, and forcing the team to try half-finished features. The first shows how the product behaves under a genuine workload; the second steals the team's time and eventually breeds a habit of 'it's probably broken anyway'. The measure is simple: internal use must actually run real work. If it does not, that is testing, not use.

To preserve that distinction, internal use needs a quality bar of its own. If a feature is opened for internal use, its core flow must at least work and it must carry no risk of data loss. Our rule: what is opened internally may not be mature enough to ship, but it must be dependable. The place for experiments is the test environment, not the place where work gets done.

In a team that uses its own product the biggest risk is that bugs never get recorded. Because everyone knows the code, people either fix a problem on the spot or work around it with 'I know about that, don't go that way'. The result is a list of bugs the team knows and the system has never seen — and that list eventually surfaces at a customer.

The only way to prevent that is to make recording cheap. If opening a bug takes more than three clicks, nobody opens one; if it demands a template, has many mandatory fields, or leaves the target project unclear, it never gets opened at all. That is why in our own tracker we deliberately kept creating a record light: a type, a title and one sentence are enough, and the rest can be filled in later.

The second habit is turning 'I'll just fix it' into a record. A developer may fix a bug in five minutes, but fixing it without opening a record loses two pieces of information: that the bug existed, and which change introduced it. Those two are exactly what you need most when the same bug returns six months later.

The shadow side of using your own product is that the roadmap bends toward internal needs. Whatever annoys you rises to the top, while the customer's need may sit somewhere else entirely. Because our work is running dozens of products at once, our internal needs are more complex than most customers' — which can easily turn into the trap of perfecting a feature nobody asked for.

To balance that we use a simple rule: for a request born of internal use to enter the roadmap, it must correspond to at least one external use case. If the need is specific to us, we put the solution into our own configuration rather than the product. Keeping the product general matters at least as much as our internal efficiency.

There is no '98% customer satisfaction', no 'we tripled efficiency' and no invented client quotes on our site. The reason is not modesty but a rule: every number we publish must have a measurable source behind it. We state that rule openly to everyone producing content — only real figures go into a stats band, and nothing else does.

The most visible consequence of this rule is that some sections look 'weaker'. Our product pages carry countable things — number of modules, of screens, of languages — but no revenue impact or satisfaction rate. There is no badge band either, because we do not have a real badge yet; lining up placeholder logos because others do looks good at first glance and bad at the second.

The same honesty applies to imagery. Some videos on the site are currently royalty-free placeholders, and we mark them as such internally; they will be replaced with footage of our own products. When a client asks 'is this screenshot real', having an answer with no hesitation is worth more in the long run than any design trick.

In the short term it hurts; in the long term it saves you. We mark unbuilt features plainly on our product pages, and that can leave a 'these are missing' impression on someone comparing lists. In return, a client who meets no surprises in the sales conversation speaks with the same confidence after delivery. Setting expectations correctly is easier than managing them later.

There is also this: a list that admits its gaps makes the rest credible. A feature list where every item is unmarked makes the reader wonder whether all of it really exists. A list that honestly says 'this one is not here' implies that the others genuinely are. Honesty here is as much a communication advantage as an ethical choice.

The most concrete form of the honesty rule is the references page. Publishing a client's name, logo or the details of their project requires permission, and even when it has been given verbally you should get written confirmation. This is a matter of professional manners as much as legal caution: turning a client's internal processes into marketing material is not something to do without asking.

When permission cannot be obtained there are two paths: not telling the story at all, or telling it anonymised. The second is harder than it looks — give the sector, the city and the scale together and most projects become identifiable. The question to ask when writing an anonymous case: if the client's competitor read this, would they know who it is about? If so, it is not anonymous enough.

Our choice was to leave it empty until real permission arrives. We line up no invented logos in our references section and tell no case that did not happen. That makes the page look weaker today; but when a client asks about 'that project of yours', we have a real story to tell. When the choice is between short-term appearance and long-term trust, we take the second.

No, and that has to be accepted. If you write clinic management software you do not run a clinic; in a flight operations product you own no aircraft. In those domains what replaces your own use is a close relationship with the person doing the work: sitting beside them at the screen, seeing how the day flows, testing your assumptions right there.

The second compensation is finding the part of your own work that resembles the product. In a booking product you can run your own meeting schedule with it; in a document product, your own contract flow. It is not full use, but it beats no use at all; at minimum you learn how the core flow feels in daily life.

The value of your own use is limited by how much it resembles the customer's. We are a team running dozens of products at once; a customer runs a single business. For us 'switching between many projects' is a daily need, for most customers a situation they never meet. Generalising your own experience without knowing that difference is the easiest way to bend the product toward yourself.

We do two things to balance this. First, we run every request born of our own use through the question 'would a single-location business need this too?'. Second, we watch someone using the product for the first time and note where they hesitate; a task we do in five seconds taking someone else two minutes is a measure of our habits, not of the screen.

The precondition for being honest outwardly is being able to speak honestly inside. If saying 'this feature is actually half-done' is punished in a team, that sentence is never said before the sales meeting — and it is not said there either. The origin of presenting unbuilt work as built is usually not bad faith but the fact that carrying bad news is costly.

The practical counterpart is being able to mark the state inside the product itself. If a module can sit in the catalogue as 'soon', carrying that information no longer depends on anyone's courage; it becomes a normal state of the system. Protecting culture with structures that carry the rule works better than protecting it with rules — people forget, but a field does not stay empty.

Finally, one direction of honesty points at your own decisions. If you designed a feature wrongly, roll it back instead of defending it; when you see a decision has not worked, write it down and change it. Our memory files contain notes beginning with 'this turned out wrong', and those are the most valuable ones — because they keep us from taking the same road next time.

Using your own product is not a marketing line but a quality mechanism: it shortens the feedback loop, ties prioritisation to reality, and closes the distance between what you say while selling and what you deliver. Its price is accepting work with an immature tool, and never neglecting to bring in outside eyes against the blindness of habit.

The second half of this position is not inventing. Let every number you publish have a source, every quote an owner, and every 'soon' a genuine reason. We pay the price of that on our product pages and will keep paying it; because whether a client gives you a second project depends on what you did not tell them the first time.