Far too many digital products fail.
They are over budget, deliver a bad user experience, have poor adoption, and they don’t generate the promised Return On Investment (ROI). Managers hire big consulting firms to help them figure out what ’solution’ to build. It's expensive, frustrating, and often the result is underwhelming - if not completely underwater. We need to change how we view these projects: they are products. Our end users are our customers. If they aren’t satisfied, delighted, and don’t habitually use it, then the product is useless, the business doesn’t get the ROI it was promised, and we have failed.
This is madness and there is a better way.
I believe, as do many others, that putting end-user experience first is the most effective way to deliver real results. I also believe that small teams – that offer design-focused, human-centered solutions to satisfy the boundary conditions set forth by business-needs – are in short supply these days. Managers still hire big firms to do product development and they consistently miss the mark. Managers and product owners feel lost without good options, and many expensive projects fail.
If you google “why IT projects fail” you get a lot of lists. Few of them ever mention team size. With modern tools, we’re able to do so much with a small team of professionals, and it actually gets harder to nail the nuance of UX as team size increases. In addition to communication complexities, individual team member contribution goes down as team size increases1. In this article, I will explore team size and its relation to delivering a delightful experience. We should strive for and invest in creating delightful experiences because they lead to habitual use which in turn leads to ROI.
If we use user experience (UX) design the right way, then we de-risk the project, lower cost, and increase ROI. Again, I believe the best way to do this is to utilize a small team of pros, not a huge bloated consulting firm. So if business-centered projects are underwhelming and cost too much, then the antidote is user-centered (read: ‘obsessed’) projects with small teams that deliver the right things.
Imagine an organization of 10,000 people who have a problem they hate. These people will find time-sucking workarounds to avoid that problem. The business ROI for a project that fixes that problem relies on the company adopting the solution and abandoning their workarounds. Wouldn’t it be refreshing to produce a product that takes something hard and makes it easy, makes your company money, and gets delivered on time?
To build products with great UX, corporations need a relatively small team of pros that think disruptively and communicate nuance fully. Small teams of real problem-solvers, that can solve, design, and build performant and scalable technology, are the future. Many successful projects were built by small teams of innovators that all understand their individual contribution, not 300 consultants. The Gmail team was tiny, around a dozen people, when it launched publicly3. Small teams can do big things!
Building ‘software’ is not building ‘product’. The ’software’ part is often the ‘easy’ part. It still has to work, and be secure - and doing that well is complex and takes highly skilled people. Knowing what problem needs to be solved for your users, and figuring out what a delightful solution looks like, is the real hard part. You can’t just hire a software company and expect a product to pop out of the other side. It takes an intense focus on design. Similar to hiring an architect to design your home before you hire a builder. It’s 10 times less expensive to experiment and learn from users in the design phase than in the build phase2. Why anyone would ever run 10x more expensive experiments by jumping hastily into a build phase is beyond my comprehension, but it happens all the time.
Recently, Accenture and Hertz have been in the news due to an expensive, and frustrating project to rebuild the Hertz web platform and mobile app. They paid Accenture over $30M and were so disillusioned with the result that they are suing Accenture for delivering a product that doesn’t work4.
This madness has to stop.
Great champions of projects within an organization care deeply about whether or not the end result actually works. It’s not good enough that the project was delivered on time and my career advances— it must do what it’s supposed to do. If a product doesn't fix a frustrating process or if people aren't delighted when they use it, then we should not build it. To a savvy product champion, success means that you have built something that people need and love to use. How many times has your organization hired a big expensive consulting firm and had the result be something the customer actually loves to use? It doesn’t happen often. Despite the poor performance of large agencies when it comes to building custom products, business owners still hire them.
Want to build a successful product with a small team? Here is how to do it.
I. Understand the end-user
Do you know why most products really fail? Because they don’t understand the real needs of the end-user. Your organization wants something out of it… to drive efficiency or reduce admin costs, perhaps. But the end-user wants you to take something that was hard, frustrating, and time-consuming (or all three) and fix it. Designing a product around THEIR needs means they will use the product a lot, and the by-product of a high adoption rate is success with your organizational ROI. Additionally, when you provide end-users with great tools, they are satisfied and loyal. They feel like the organization or brand cares about them because it provides great tools for them to use.
II. Hair-on-fire problems need delightful solutions
In the consumer product world (or anytime it’s not a mandatory rollout), if you don’t address a hair-on-fire pain-point with a delightful solution, then nobody will buy your product. I’m part of a project team at Anthroware that is working for a large company in the healthcare industry. They have an organizational priority of creating more connections amongst their members. After doing some user research we found that the members thought more connections were cool, but really they wanted an easy way to do two other things. Finding out the most important “job to be done” for the end-user and prioritizing that, drives them into the product, and then we can subtly and effectively carry out the organizational goal of creating more connection.
III. Creating ROI by focusing on the end-user
Bottom line, the needs of the people that are going to be using the product are always the same as the needs of the organization. If you address their needs first, then they will habitually use it, need it, love it, and thank you for it. When users love a product, then the organization benefits (more sales, less time by employees spent on mundane tasks, etc.).
Sometimes stakeholders have a tough time grasping user needs. There are many ways to involve the project’s stakeholders in this UX process. It can be really fun, and everybody feels heard. Many studies suggest that involving executives in projects increases success stats. Think about how powerful it would be to have an executive help you facilitate a UX interview. They’d see first hand what people are dealing with, and the importance of UX and design work as it pertains to nailing the right set of experiences. Nailing the experience is what really makes a significant difference with things like efficiency, throughput, happier end users/employees, etc. User-focus also forces intense clarity for what you should be prioritizing and why. Knowing the top jobs to be done for your end-users allows you to prioritize with authority. This saves money in the long term, and further aides in team alignment.
IV. Features vs. Experience… what’s enough?
It’s easy to make an ROI look good on paper. A list of features is NOT the same as a list of experiences or top ‘jobs to be done’. If I told you about a meal — a perfect risotto made with homemade broth, stirred constantly for a perfectly creamy texture… the addition of wild mushrooms and shallots… topped with a perfect bone-in pork chop and a peach chutney — you could picture a delicious plate, right? What I stated was actually a list of features. Ingredients. You got a sense that I was putting time into making the risotto, but what about the proportions? What if the whole dish had only one mushroom? What if there was a tiny piece of pork with a gallon of risotto? What if I didn’t plate it at all, but put it all in a blender and served you a rice and meat milkshake? The list of ingredients is the same in the milkshake, but that’s not the experience you were expecting. The preparation, portion, plating, amount of cook time, even the atmosphere in which you are served, all impact the experience. If the experience is good, then you’ll keep coming back for my risotto.
It’s easy to communicate a list of ingredients to a big team, but it’s hard to get a big team to understand the nuance of the experience you’re after. Could you imagine a team of 300 cooking risotto?
You need to obsess over the experience your user wants. A list of features is lazy and doesn’t tell the whole story. You have to deliver the harder, more nuanced thing. Once you know what’s important to your end users you can focus on how to prioritize the right experiences. What you deliver has to be so good that your end-user will stop their current way of doing something and develop a new habit around the solution you’re presenting them instead. It’s very hard to change habits. In our playbook, we’ve dubbed this the “semiconductor product theory”:
The Semiconductor Product Theory
Getting anyone to change habits is hard. Even if your solution is “better”, it may not be different enough or improved enough to warrant a behavioral change. With our clients, we should be keenly focused on finding one or two user experiences that are so much better, so amazing, that they stop what they are doing now to buy and use the product we’re making.
Semiconductors can hold charge (electrons) in different states (1 or 0) because there’s a gap of semi-conductive material between two pieces of conductive material. If enough energy is put into the electron, it can cross the gap and live on the other side. If it doesn’t have enough energy, then it can’t cross and ‘falls’ back to where it started. Ok, in reality, it's a little more complex than that, but bear with me. In figure 1, scenario A shows a visual representation of something that doesn’t have enough ‘energy’ to change someone’s habit. End users are a lot like semiconductors in that they won’t change, or learn something new, or spend money on something unless they perceive that it’s going to be WAY better. Scenario B shows an experience that is so much better that people will stop doing it the way they are doing it now (current state), and buy a new product (improved state).
The experience you deliver has to cross that gap in order to change habits. Thinking as a digital anthropologist, you should look for the 1 or 2 things that bridge this experience gap. What’s ‘enough’ for a 1.0 version of your product = building the experiences needed to cross this gap.
V. Small teams build better products
If you want to deliver a truly delightful experience, then the entire team has to be aligned. The more people you add to a project, the harder it is for your product team to all be obsessed with your end-users. The larger the team, the more communication issues come up, the more time it takes to align the team, and the harder it is to breathe life into the fragile spark of a new product. It becomes easy to revert to the ‘list of ingredients’ instead of obsessing over the nuanced experience that invokes delight with our users. Small teams more effectively deliver nuance.
In conclusion, end-users don’t care about driving bottom-line gains for your business, they care about the experience and whether or not the product takes something hard and makes it easy for them. If you fix their problems, then you’ll get the maximum business ROI. And if you want to be successful at delivering a nuanced user experience, hire a small, motivated team.
Hope this is helpful to you, please reach out if you have questions.
__________________________________________________________
1 Ringelmann Effect
Is Your Team Too Big? Too Small? What’s the Right Number?
2 The User Experience Team of One: A Research and Design Survival Guide: Leah Buley
4 10 Lessons from Hertz's $32M Web Design Lawsuit Against Accenture
