I’m old, and I’ve worked with a lot of companies, large and small. Some employed me, while others were clients.

The most innovative and productive companies I’ve worked with had something in common: employees used the company’s products because they wanted to.

When I worked on Skyblog, Skyrock’s French blogging platform, everybody there used the product. And I really mean it: everybody. Night and day. And we had a lot of fun with it.

So we cared a lot about it as both employees and as users.

Skyblog is gone now, but my former colleagues and I still have great memories of working on it, even though we worked like crazy.

That willingness to use the product tells me more about a company than the size of its budget.

A company can hire excellent people and have a convincing plan for the future. But neither guarantees that anyone there will choose the product when they have a choice.

That’s why I like seeing employees use their company’s product for their own projects outside work. They might even be paying for it.

Using it at work can mean nothing more than testing a feature or preparing a demo for a customer. But that doesn’t tell you whether someone would choose it for themselves.

When you’re trying to do something for yourself, the product’s limitations become your problem too, so you want them fixed.

Knowing how the code works won’t spare you the annoyance of a bug that gets in your way. And once you’ve had to live with that bug, you understand the complaint a lot better than you did while reading its description.

In my experience, people who enjoy using a product already have a reason to want it improved.

They get something out of the work themselves. That sort of attachment is hard to create through pressure or a company culture program.

It also gives people ideas about what to build next: as they keep using the product, they notice what’s missing and start thinking about how they’d like it to work. So they can suggest something useful before a customer has had to ask for it.

A product manager can know the market very well and still get something out of using the product every day. Developers can too.

Building a feature and relying on it for your own project give you different experiences, and I’ve learned to be careful about assuming one gives you the other.

For that to work, employees who report a problem need the same attention as other customers.

They should be able to get an answer without having to chase several teams. If a report from an employee is harder to get addressed than the same report sent through customer support, something needs fixing in that process.

And people who enjoy using a product recommend it to others. They can explain why it’s useful because they’ve relied on it themselves.

That can benefit the company years later, when a former employee recommends the product to colleagues at another job.

Their new company may become a customer because someone there knows how to get useful work done with it. Having worked on the code alone doesn’t give someone the same experience to draw on.

Customer requests are useful, but if every change starts with a request from a customer or a potential customer, the company is always waiting for somebody else to identify the next thing to do.

Employees who use the product can bring ideas of their own.

So when I think about what helps a company come up with useful improvements, one of the first things I’d look at is whether its employees choose to use what they’re building.