A person in a virtual reality headset, head tilted up, reaching out with one hand toward something only they can see

Why I wrote this

I've worked on products across e-commerce, marketing, finance and telecommunications, in startups, a media group, product companies and large corporations. My roles have ranged from sales and customer support to graphic design and product development.

These are situations I still remember and the lessons that changed how I think about products. They come from different companies and different stages of my career. This isn't a handbook or a chronological account. I've left out identifying details to focus on the lessons. I write mostly about software, but most of this applies to physical products too.

1. The product that did the exact opposite

Our product was integrated with a client's online store and its job was to recover abandoned carts. It worked reliably for a long time. Then the store's customers could no longer complete their purchases. The client ran an analysis and concluded that our integration was blocking the checkout. A tool meant to save carts was making people abandon them. The client called, angry: our product had caused an outage and they were losing money. By then the integration was already disconnected.

First, take the client's problem seriously. Establish the cause after that. We said we understood the situation, asked for their analysis and started checking on our side. Along the way, one question: have you made any changes to the site recently? They had.

The conflict appeared after changes in the store. On our side, we had to change how the integration worked so it could handle those changes better. We did that and after some time the client reconnected it.

The incident also changed how we approached integrations more broadly. Once one client's problem was solved, a question remained: how many others could run into the same thing? Our product worked across many e-commerce platforms and any of them could change without us knowing. So we reviewed the code and the way the integration loaded on different sites, and made changes meant to make it more resilient to changes on the client side, instead of waiting for the next phone call. Not every complaint calls for a new feature. Sometimes what's needed is a change in default behaviour, in documentation, or in how errors are detected.

Takeaway: take the problem seriously and help limit its impact without waiting for a full diagnosis. Don't assume the cause lies with you or the client before checking. Once service is restored, don't stop at the quick fix: investigate what failed, why it failed and which other clients might be affected.

2. Your product never works alone

What is a standalone product to you is a piece of a larger process to your client. Even when there are no integrations at all. That process lives and changes without your knowledge.

Take a chatbot on a website. From the outside it's a small window in the corner of the screen that answers questions. In reality it plays different roles depending on who deployed it. For one client it's a shortcut to information, because their site is hard to navigate. For another it's the first line of support: it gathers details about the issue before anyone reaches a support agent. For a third it's a sales channel, because it speaks up when someone has been browsing the products for a while.

The conversation doesn't end in the window. What the user types travels on: to the CRM, to the complaints system, to the warehouse, to the reports someone makes decisions on. If the chatbot misclassifies a ticket, the complaints team gets it late. If it promises a delivery date the warehouse knows nothing about, it won't be the chatbot explaining itself to the customer.

Takeaway: whatever you build, assume it runs next to systems you don't know exist. Ask about that context before you deploy.

3. Agree on value before you start measuring it

An example: a product recommendation engine. The marketing says "increase your sales by 10%". In practice it depends on how the engine is built and what data it has on day one. If personalisation relies on behavioural history, it may have limited capabilities at the start. Depending on the solution, you can then lean on the store's historical data, product attributes or simple rules. What matters is the amount and quality of data and the traffic in the store, not the passing of time on its own.

You have to explain this to the client from the ground up, in plain language: how it works, what it needs to work well, and when to expect the first results. Legal questions are a separate thread: which data can be used, what the user has to consent to. That's a topic for another text, but it also has to be said at the start.

And one more thing I learned late. Before the rollout, it's worth agreeing on what is supposed to change, for whom, and how we'll know the change has happened. Otherwise the vendor shows a rise in clicks while the client is waiting for less work or a better margin. The two sides look at different results and have different definitions of success.

Takeaway: if your product's value depends on conditions, say so at the beginning. And agree with the client on how you'll recognise that value before the first report lands on the table.

4. Classic mistakes I've made

Looking back at the products I've worked on, I see a few prioritisation mistakes I can recognise easily today.

Building for the loudest client without checking how many others share the problem.

Building for the single biggest client instead of many smaller ones. When the big client leaves, you may be left with the cost of a feature nobody else needs. And a feature doesn't stop costing money on the day it ships. Maintenance, tests, documentation and its effect on every later change stay with you.

"We think that..." I have nothing against intuition. Plenty of good products came from the intuition of a founder, a team, or someone on the sidelines who tossed in an idea. But an idea born of intuition is worth discussing with people and testing against data, not only to confirm or kill it, but to see the risks. Often the data isn't there and then you simply have to take the risk, knowingly.

A few times that intuition paid off. I remember when push notifications arrived in browsers (Chrome added them in 2015). We came in early with a product: notifications sent straight from the store, a more direct way to reach customers. At first the channel worked very well. Over time, in our deployments, similar results became harder and harder to get.

Takeaway: before you build something for one client, check whether it's a deliberate direction for the product and whether you've counted the cost after launch. And treat intuition as a hypothesis: valuable, but to be tested.

5. Help diagnose the problem, even when your product isn't the cause

You supply a product to online stores. A message goes out from your tool, people click, they buy, the system reports the results. Then the typical store problems begin: someone's discount didn't apply, someone didn't get the email, a parcel didn't arrive. Some of this touches your product. Some of it has nothing to do with it. The client writes to you anyway.

I remember a complaint that, once traced, concerned a purchase made in a completely different channel than ours. Companies sell in many ways, the person responsible for a given process is on holiday, someone forgot something. They write to you because you're the partner they trust.

The temptation to reply "that's not our product" is strong. It's better to ask a few questions: what happened, in which channel, when. Sometimes that's enough for the client to take those questions to the right team and find the cause. Helping doesn't have to mean owning the problem for good. The point is that the client leaves the conversation with a next step, not a refusal.

Takeaway: a client often starts with the vendor they suspect is the source of the problem. If that's you, and it wasn't your fault, help them get to the truth anyway. The relationship gets stronger for it.

6. When the product doesn't deliver

This is probably the hardest situation in business. The client says the product isn't delivering value. You can deny it and bury them in numbers. Or you can do what we did a few times when the decision to part ways was already hanging in the air: put the cards on the table. Data from our systems, data from the client's, and we look together.

Sometimes the value problem is plain to see, and then you can honestly propose an optimisation: configuration changes, a three-month discount, followed by a review of the results. And sometimes the measurement has to be fixed first. In our cases the client usually had several tools serving the same goal at once: email, social media ads, SMS, offline activity. A user arrives from an email, clicks another vendor's message, leaves, comes back from Facebook, clicks ours, buys. When the sale is credited to the last click, the earlier contacts with other channels vanish from the assessment. There are models that split credit between touchpoints, but you need to know which model sits behind the report both sides are looking at.

There's a second layer to this problem. A report can credit us with a sale that would've happened without our product. Shared rules for counting are the beginning of a conversation about value, but they don't settle it. Measuring the additional effect takes a separate approach, for example an experiment with a control group that doesn't use the solution being tested. It's more work, but it helps estimate what share of the result is really the product's doing. Sometimes, after a joint analysis, you also have to admit that the product doesn't fit the client's needs and no further optimisation will change that.

Takeaway: don't be afraid of the numbers, even when they aren't on your side. But first agree with the client on how those numbers are produced and what they actually measure. Reviewing the data together is better than ending the relationship in frustration.

7. Onboarding and offboarding

Onboarding is standard these days, yet I still see it underrated. A client who buys a product doesn't always have time to configure it, and sometimes not even to use it.

A typical scenario: one person in the company uses the product. That person gets sick, goes on leave, or quits. The client is left with your product, paying real money for it, and with nobody who knows how to operate it. The person who knew the product best is gone, and the product becomes an orphan. That's why it's worth having an onboarding process ready, whether guided by a person or automated, with documentation that answers practical questions. It's invisible value that shows itself in hard moments.

Offboarding matters just as much, and people rarely talk about it. This client may never bring you money again, but how you say goodbye is worth a little time. Sum up the collaboration, say thank you, ask what led to the decision. A good offboarding process also lets clients export their data, disconnect integrations and understand what will stop working. The culture of a partnership shows in how we designed the exit, too.

Takeaway: don't pick a fight at the very end. Establishing responsibility is sometimes necessary, but it doesn't have to mean a quarrel. Part ways with grace.

8. Watch how people actually use the product

Clients don't always use a product the way you designed it. A chair is for sitting, but it also serves as a footrest, a side table, a camera stand, or a platform for photographing the dog. If people regularly stand on your chair, you've spotted an additional need. It's worth checking whether the product can meet it safely and what would have to change before you start selling it as a step stool.

With every product I've worked on, there was a group of clients using it in a way we hadn't foreseen. We didn't advertise it, but the product did it and people were happy. There's often value hidden there that can be delivered at low cost.

The other side of this observation: not every client needs the whole product. It's worth checking which features bring value to which groups of clients and which ones are their reason to stay. But frequency of use doesn't tell the whole story. Data export or access recovery may be needed rarely, and that's exactly when they decide whether the product can be trusted. Before you call a feature redundant, ask what happens when it's missing.

Takeaway: watch the uses you didn't plan and the features used rarely. Check what they give clients before you judge their importance.

9. Industry, seasonality, trends

No two businesses are alike, even within the same industry. In e-commerce, selling clothes is not selling car parts, and neither is selling wedding dresses. Each segment has its own trends and its own seasonality: Black Friday, the holidays, the seasons, back to school. Over the year your product will be used more intensely at times and less at others. Quieter periods can be a good moment for fixes and housekeeping, provided you have people on hand to handle incidents and the process you're touching isn't critical for someone right then. Even if traffic drops over the holidays, so may the availability of your team.

The second thing is trends. A lesson you have to teach yourself: tell apart trends that come from real client needs and trends generated by solution vendors. Some are driven by hype. Someone copied a thing because it worked for someone else, the market turned, and everything stopped working, the original and the copy alike.

Takeaway: look from several angles. What you do, what the competition does, but also what's happening to your clients: a crisis in their industry hits you indirectly.

10. Listen to clients, but don't do literally what they say

What a client says isn't always what they need. Sometimes they sense something is off but can't name it. Sometimes they point at the wrong solution: "yes, this will solve our problem". Cognitive biases, gaps in knowledge, seeing everything through the lens of their own industry. Our interpretations are open to the same biases, just from the other side of the table.

This is where the product person and the UX people come in: ask questions and check whether there's a simpler solution. Building a cannon when a simple fix would do can damage the relationship. The client is thrilled by the ambition at first, and then it turns out that wasn't it.

This doesn't mean the product person should spend all their time talking to clients. You have a support team, sales, technical service. These are people on the front line and a valuable source of insight into the problems clients face. That knowledge doesn't give the full picture, because you hear loudest from those who report problems or are in the middle of buying, but it can quickly supplement research.

Takeaway: look for the problem beneath what the client says, and check your own assumptions the same way you check theirs. Draw on the knowledge of people who talk to clients every day.

11. Deadlines, expectations and involving the client

When you build a product and promise dates, you won't always keep them. The reasons vary: random events, availability of resources, shifting priorities. Let the client know as soon as a deadline is at risk, so they have time to respond.

What works even better is involving the client in the building process, if they have the time and the will. Consult, show, ask. When a delay comes, it's easier for them to understand the reasons, even though the consequences remain. There's another benefit for product development: the perspective of a different industry and the experience of the specific person in the meeting. Because it's not a company that attends the meeting. It's a person.

Takeaway: talk about delays early. Better still, involve the client throughout development, before a delay becomes an issue.

12. There's always a person on the other side

Sometimes the owner, sometimes a manager, sometimes someone who started a week ago. People with their own problems, not always pleasant and not always with time for you. Empathy works both ways: when you're the one having a bad day, give yourself a breather or hand the conversation over to someone else. A workshop can be rescheduled.

Remember too that the person who buys the product isn't always the one who uses it. The CEO buys, others use. Some of them wanted the product, some thought the purchase was pointless, others found out about it after the fact. Some want to talk to a human, for others the documentation is enough. So before onboarding it's worth knowing: who will use the product, how the purchase came about, and what similar tools they already use. And if the product goes to several markets, you also need to account for cultural, linguistic and legal differences.

Which leads to something that's easy to forget when you're proud of your own features. The client compares our product not only with the competition. They also compare it with staying with what they already know. Even a better tool means learning, migrating data and changing habits. The benefit has to justify that effort, and the effort is borne by specific people, often not the ones who signed the contract.

Takeaway: you're designing for people with different attitudes, not for "the client". Find out who they are and what they have to give up to start using your product.

13. Now more than ever: ask before you build

Today AI can shorten the road to the first working version of a product to a single weekend. That's good news, but it has a flip side: it's just as easy to flood clients with products nobody needs.

More and more often I see apps built by one person for their own use, with exactly one user: the one who made it. Such an app can serve its purpose perfectly and needs nobody else. The question about other people's needs appears only when you want to make it available to others. Then the questions from this article return: does the product fit someone's workflow? What other systems will it work alongside? Who will actually use it, and what will they need to give up to get started?

The second consequence: if the core features are easy to reproduce, it's worth knowing what, beyond them, makes a client pick your product and stay with it. Access to customers, data, integrations and trust take longer to build than an interface. You've got traction? Great. Now think about how to keep it, and not only in terms of sales. How will you maintain the quality of code that a machine largely generated? How will you look after security and usability? Is the product flexible enough to respond to what clients will start expecting once their work depends on it?

Takeaway: AI can speed up building. You still have to answer the questions: what, for whom, how and when. These days they need asking more often, not less.

Closing

Your product is never alone. It runs in an ecosystem of other tools, inside someone's process, shaped by their industry and its seasonal rhythms, in the hands of specific people who use it differently than you planned. Most of the hard situations I remember came from forgetting that for a moment.

Simple things that are easy to forget in the rush:

  • Limit the impact of an outage right away, but don't assume the cause before you've checked. After the fix, find out what failed and how many other clients might be affected.
  • Your product is a piece of someone's process. Learn that process before you deploy.
  • Agree with the client on how you'll recognise value before the first report lands on the table.
  • Before you build something for one client, check whether it's a deliberate direction for the product and what it will cost after launch.
  • Onboarding and offboarding matter equally. Part ways with grace.
  • If features are easy to reproduce, understand what else makes clients stay and how you'll sustain that value.

These aren't the only paths. They're my reflections from real cases, across different organisations.

Sources

← Back to blog