Good Technology Starts by Asking What People Actually Need

One of the most useful things we have ever watched at The Depositary was a mouse cursor wandering around a screen. It was relatively early in our development journey, when we had started video-capturing how different groups of users actually interacted with the platform. We understood the journeys intimately because we had designed them, tested them and discussed them endlessly, but watching somebody use a product without any of that accumulated knowledge is a very different experience.

In this particular case, some tenants were reaching a point in their journey and clearly weren't sure what to do next. You could literally watch their mouse icons roaming around the page looking for somewhere to click. Nobody had necessarily complained that the platform was confusing, and they certainly hadn't submitted a detailed piece of UX feedback explaining that our calls to action lacked sufficient prominence. Their behaviour told us everything we needed to know. We subsequently rebuilt our action buttons to make them clearer, more concise, more attention-grabbing and, crucially, more logical.

I found myself thinking about those wandering mouse cursors during my recent Viking Chats conversation with Paul and Anna Moynihan, founders of TaskHer. Their business is very different from ours, but their journey has involved a similar process of discovering that there can be an enormous gap between how you imagine somebody will use a product and what happens when you put it into their hands. It is one of the reasons I think the best technology businesses don't simply ask customers what they want. They pay very close attention to what people actually do.

People shouldn't need to learn how your brain works

TaskHer connects customers with skilled tradeswomen, but Paul and Anna came into the business from events and marketing rather than the trades themselves. That meant a significant part of their early development involved understanding how tradespeople really work, rather than assuming behaviours familiar to them would translate into an entirely different working environment.

Anna gave a lovely example of this during our conversation. They wanted to create a community for the tradeswomen using TaskHer and initially built it using a dedicated community platform. It looked good and, viewed through the eyes of people accustomed to desk-based work, made perfect sense. The problem was that hardly anybody used it. These weren't people sitting at laptops all day checking another online platform. They were on the tools, moving between jobs and spending their working lives in vans and people's homes. When TaskHer moved that community towards WhatsApp, somewhere their tradeswomen were already communicating, it came alive.

There is a deceptively important lesson in that. Users don't owe technology companies the behavioural change their products require. We can build the most elegant portal in the world, but if somebody has to consciously alter the way they naturally work simply to accommodate our clever solution, we need to be very confident that the benefits justify the inconvenience.

This is especially relevant in proptech because we love a platform. We create dashboards, portals, apps and workflows and then sometimes appear surprised when the people we built them for don't share our enthusiasm for logging into yet another system. The user rarely cares how technically impressive the platform is. They have something they need to accomplish and, from their perspective, the quality of the technology is largely determined by how easily it allows them to accomplish it.

Sometimes your users give feedback without saying anything

We've gone through several phases of recording user engagement with The Depositary and have recently deployed another product to begin doing it again. Alongside recordings, heatmaps are particularly useful because they help us understand where somebody instinctively thinks they should go, what attracts their attention and where hesitation or confusion occurs.

That matters because The Depositary doesn't have one homogeneous user group. Our agent users receive training and generally use the platform repeatedly, so familiarity develops quickly. Landlords and tenants are different. They aren't going to receive software training before using The Depositary, nor should they need to. For them, the experience has to be intuitive from the outset, whether that means the language we use, the information we present or the obviousness of whatever action needs to happen next.

It is easy for a technology company to blame the user when somebody doesn't understand an interface. We know where everything is because we've spent thousands of hours inside the product, but that knowledge can actually become a disadvantage. If hundreds of users instinctively look in one place for something we've put somewhere else, repeatedly explaining where we've put it isn't necessarily evidence that they need better instructions. It might be evidence that we've put it in the wrong place.

That doesn't mean every process can or should be reduced to a couple of enormous colourful buttons. Tenancy conclusions involve evidence, money, negotiation, compliance and several parties whose interests don't always align perfectly. Some complexity is unavoidable. Our responsibility is to make sure the technology helps people navigate that complexity rather than adding another layer of its own.

Listening to customers doesn't mean building everything they ask for

There is another side to user feedback which doesn't get discussed quite as often. Listening carefully to your customers is essential, but blindly building everything they request is not the same thing as developing a good product.

We've had agents request features that make complete sense for the way their particular business operates. Sometimes those conversations reveal something useful that can benefit a much wider group of clients, and plenty of our ongoing development has come directly from agents telling us about the realities of their working lives. At other times, however, the request solves a highly specific problem created by the way one business happens to operate. If we automatically built every one of those requests, The Depositary would eventually become a cluttered collection of individual workarounds rather than a coherent solution.

This is where expertise matters. We came into The Depositary with a broad knowledge base and decades of operational experience in lettings and property management. We understood tenancy conclusions before we started building technology around them, which I believe remains one of the reasons our proposition is difficult to replicate. We weren't looking at an unfamiliar industry from the outside and deciding which bit might be ripe for disruption; we had lived the problems ourselves.

The most useful agent feedback therefore tends to be less about reinventing the fundamental proposition and more about making the platform work better within the reality of an agency. That might mean improving functionality, removing friction or recognising that the way somebody actually performs a task is slightly different from how we imagined it in development. Our job is to listen carefully enough to understand the problem being described while retaining enough product discipline to decide whether the proposed solution is right for everyone else.

There is rarely only one user in property

One of my biggest frustrations with some proptech propositions is the tendency to focus entirely on one stakeholder. Delivering technology that genuinely works in property means understanding that an agent, landlord and tenant can all interact with the same process while experiencing it completely differently.

You could build a platform entirely around what the agent wants and create something wonderfully efficient for their team, but if the landlord or tenant experience is dreadful, you've merely moved the friction somewhere else. Worse, the consumer doesn't necessarily blame the software provider for that experience. They may resent the agency that forced them to use it.

The opposite problem happens too. Somebody has a bad experience of buying, selling or renting a property and concludes that the process is fundamentally broken. They then set out to build the thing that will finally “disrupt” it, without properly understanding why some of the apparent friction exists. There may be legislation behind it, competing responsibilities, risk-management considerations or simply the operational reality of delivering a service involving large numbers of people and properties.

That doesn't mean the incumbent industry gets to use complexity as an excuse for poor service. Far from it. Some processes absolutely are ridiculous simply because nobody has challenged them for years. But there is an important difference between questioning why something happens and assuming it happens for no reason.

The best technology sits somewhere between those extremes. You cannot always place every stakeholder on an equal footing of influence because there will be moments when their interests genuinely differ, but you need to understand all of them. Ignore a significant participant in the process and eventually the consequences will surface somewhere in the experience.

Sometimes the clever solution is the simpler one

One thing I particularly enjoyed about the TaskHer story was that their learning hasn't simply resulted in them piling more technology onto the platform. They started with three tradeswomen covering London and have gradually adapted the proposition as they have understood more about the different ways those tradeswomen work. Some use TaskHer to supplement a full-time job, while others depend much more heavily on the platform for their workload, which in turn has required TaskHer to think carefully about how jobs are allocated and how the technology behaves.

That willingness to adapt matters because technology businesses can easily confuse progress with functionality. Every new feature feels like an achievement, particularly when you're selling software and a longer feature list gives the sales team more things to talk about. Yet a product can become substantially worse while technically becoming capable of doing more.

Our objective at The Depositary has never been to use as much technology as possible. It is to make tenancy conclusions easier, faster and better. Sometimes that requires sophisticated development and integrations; sometimes it means removing something, automating something that nobody should have been doing manually or making an existing interaction so obvious that nobody notices the thinking behind it.

That, to me, is what great technology increasingly looks like. It doesn't demand admiration from the person using it. It quietly removes the things that used to make their life harder.

Why we resisted the temptation of early investment

Another part of Paul and Anna's story resonated strongly with our own journey. They talked about resisting a “growth at all costs” mentality and, in the case of expanding TaskHer into handiwork, deliberately taking time to understand how they could verify people and manage the risks before racing towards an obvious commercial opportunity. Demand existed, but that didn't automatically mean they were ready to serve it properly.

From the very concept of The Depositary, we made a similarly deliberate decision to resist outside investment. It wasn't because we thought investment was inherently bad. Plenty of brilliant businesses have been accelerated by external capital, and there are circumstances where it makes perfect sense. Our concern was what significant investment too early might do to our priorities.

We knew The Depositary would ultimately succeed or fail on the quality of its technology and process. Big investment at concept or MVP stage would inevitably have created pressure to grow quickly, acquire customers and demonstrate commercial momentum. We weren't prepared to put ourselves in a position where sales had to run ahead of the product simply because investors expected a particular growth trajectory.

There is an additional challenge with our particular proposition. Some proptech businesses have a legitimate revenue-generation component, whether that's producing leads, generating instructions or creating an additional income stream for the agent. If the product is a little clunky in its early days but it is simultaneously putting money into the agency's bank account, customers may be prepared to forgive some shortcomings while the technology catches up.

The Depositary has very little room to hide in that respect. The value we promise is predominantly delivered through substantial time savings and a better customer experience. If the technology doesn't achieve those things, there isn't another revenue-generating benefit distracting the client from an underwhelming product. Our platform has to substantiate the claim that it makes tenancy conclusions easier, faster and better because that is fundamentally what clients are buying from us.

Build something worth growing first

There is an understandable obsession with scale in technology. How many users? How quickly are you growing? How much have you raised? Which new markets are you entering? Those are all legitimate questions, but they can become dangerous when growth itself becomes evidence that the underlying product must be good.

For The Depositary, we wanted the sequence to work the other way around. Build a genuinely good solution first, prove that it saves time and improves the experience, listen obsessively to the people using it and then earn the right to grow it. That approach may not create the most exciting investment announcement during the early years of a company, but it creates something rather more useful: a product people actually want to keep using.

The conversation with Paul and Anna reminded me that the same principle can apply even when two businesses are solving completely different problems. TaskHer learned that tradeswomen working from vans behave differently from people sitting behind desks. We learned that a tenant moving a mouse aimlessly around a screen was giving us incredibly valuable feedback without ever submitting a support request. In both cases, the important thing was being willing to observe what was actually happening rather than insisting that users behave as the original product design expected them to.

Good technology doesn't begin with asking what clever things we can build. It begins with understanding the problem properly, recognising everyone affected by it and remaining curious enough to change when real-world behaviour challenges our assumptions. If we get those things right, the technology itself should increasingly disappear into the background, leaving the user with something far more valuable: a process that simply works.