There are a thousand ways to fail in executing a digital product project. Regardless of the many variables, failure to deliver a project will always be due to foundational risk factors that compromise its successful completion.
It’s been almost 20 years since I started my career in product design, and, as you might imagine, many things have changed dramatically since then. One of the main characteristics of the technology industry is the constant evolution of its dynamics, roles, processes, technologies, experiences, and even business models. Those changes are inevitable and will continue.
In retrospect, I see that there is one reality that has not changed much over the last 20 years and remains a constant issue to this day: building technology products can sometimes be a discouraging and exhausting process, from junior positions to senior management levels.
Why do we suffer every time we need to build something? Why is there so much burnout among today’s tech professionals? Why is it that, regardless of the industry, company, or technology, we always hear the exact phrases: “I’m exhausted, I feel drained by this job.”?
Well, those are valid questions that still haunt me 20 years after my first web design job. It seems like there’s no choice in this environment but to suffer.
As I mentioned before, a lot has changed in the tech industry. At the beginning of my career as a junior designer, watching leaders have complex conversations for hours was sort of a path I wanted to follow. To me, that was an expression of strategy, power, and importance within a company. Now, when I remember those meetings full of bureaucracy, all that comes to mind is a waste of time, resources, and money, but above all, not-so-clear project directions. The “tech machine” was slow, gigantic, and less efficient than it is now.
A few years later, the agile methodology hit the industry with a beautiful promise: to build products without needing the perfect scenario or the final product; instead, a quick, viable version will work as a measure of user feedback, which will lead the product to evolve. Agile is still a living practice today, and many companies and teams use it to shape product development dynamics. But was agile the final solution we needed to make the tech product creation less painful? My answer is NO, it wasn’t, and the reasons why, no matter frameworks or methodologies, we are still stuck in a toxic product-creation spiral are due to these factors.
The three risk factors of building a tech product:
Unsuitable people for the role
This factor is the number one cause of a product project’s failure. When you have people who are not suited for the job, the consequences might be catastrophic for everyone and everything involved. Why is this factor the most dangerous in a project’s building process? Because at the end of the day, it’s people who are responsible for control and making things happen from the beginning to the final stages, not technology or some autonomous process, so when we talk about products and quality, we are actually pointing to the people who made it possible.
“All products are a mirror of the people who built them.”
Regarding non-talented people in technology, I’ll talk about roles such as product, design, dev, and other positions involved in creating digital products. Part of the issues that surface when dealing with unsuitable people in a project are:
Business misunderstanding: People who are unable to understand where the company or the product is going are highly likely to make wrong calls and take the project in the wrong direction, creating a waste of time or money, discouragement within the team due to the constant re-work, and from that point on, all efforts will be inefficient. Consequences of this issue: missed dates, unclear or unconvincing project goals, inefficient metrics, and confusing product expectations, or what I call “ghost problems,” which are the product’s functions that were never considered to have, and people for not understanding all the product’s functionalities, expect.
Lack of systems thinking: Untalented people are unable to see the project as a connected entity, part of a whole, with serious consequences at all stages, especially at the final stage. One of the basic things to master when starting a new project is to be aware of all possible connections or collateral impacts on other products, especially if you work in a product ecosystem. Not taking this information to the table in the early stages of a project will affect planning, the accurate scale of the challenge, and potential dependencies on other actors or functionalities.
You can deliver or ship a product, but without this information, your solution is incomplete, and you will probably have to go back to square one, this time with rising costs and frustration from teammates.
Improvised way of working: I’ve seen many people start a project without a clear path, and experience has taught me that results are often poor because valuable work can be left behind. When working without a basic sense of order, you will react to everything rather than plan and take control of your next move. As you guessed, ownership here is nonexistent because your time will be spent on damage control rather than having relevant conversations with others.
Unproductive communication: Projects are simple; it’s all about progress, steps, time, capacity, numbers, and other factors. The proper language for conversations is about key information, for example: “overall progress is at 75%; so far, we have reached the following milestones, and we have these warnings that could potentially put the X deliverable in jeopardy.” I know this is a simple way to show it, and it might involve a lot of considerations, but in essence, that’s pretty much what you need to talk about.
Unproductive communication occurs when the person in charge of these conversations begins to tell complex stories with dialogue, subplots, and even twists, making the key points of the conversation unclear, leaving more doubt than certainty, and also consuming the time of the other members of the space. I think good communication is about finding the perfect tune for the message you want to deliver to the right people at the right time. Not strategically developing this skill will lead to unclear agreements (my opinion vs. your opinion), which will steer the project down subjective paths that are sometimes inefficient for the business.
No signs of accountability: Are you familiar with affirmations like this: “It’s not my fault, I shipped as expected, but the X team or the Y person didn’t deliver as supposed to.” Who loses in this scenario? Everyone, when everything is from everyone (in low-seniority environments), no one is responsible for anything.
These positions within the team are dangerous for the project and the company because you face people who don’t play fair or, at least, aren’t team players.
No problem-solving mindset: Problems are inevitable; the whole point is how to approach them. Having people who panic when things are not going well and bring chaos to the team or stakeholders is less than practical. It is just noise with no answers. A solving mindset is an underrated skill that, in my opinion, can make the difference between shipping high-quality products and delaying things to the point of generating frustration among people or killing the production momentum within the team. Problems sometimes are the fuel people need to find a differential spark that can make your product unique.
So far, in my experience, these are the things that make it challenging to create products from a human perspective. We are not perfect, and that’s a reality we live with, and it is also a beautiful thing, but it doesn’t necessarily mean that we shouldn’t do things to help navigate these complex nuances.
How to help surface these problems?
As I said, we are complex beings, and external factors can influence our everyday performance. Still, if we take an objective look at what is necessary when executing a product build, these are some simple things to consider.
Company and team context matter
Not all companies are the same, just as not all people are. There are tons of factors that make every company and its teams unique; so, when finding someone to jump into a product-creation dynamic, make sure this person is a good fit for what’s about to happen and how people interact. In companies where bureaucracy is high, for example, you may need a type of person who can handle high-power profiles or even non-technological roles. Still, the situation is different in small, agile companies, where a hands-on profile can be more productive than focusing solely on strategy or meetings. Make sure the person you are looking for has a background in a similar company and team context, as that will make the transition to the new role smoother.
Skills visible in the field, not only on a resume or a job vacancy
To me, there is a lot of bluff among professionals today who claim they have achieved remarkable things in previous positions. Still, experience has taught me that one thing is to say in sophisticated words on a resume or a LinkedIn page than to demonstrate in action, where sometimes theory is irrelevant, and the most critical thing is your ability to solve problems and make decisions for the project, team, and company. When promoting someone or hiring a new team member, make sure whatever this person says is true (for example, in a business case challenge). In this way, I’m sure that when the challenge arises, your new asset will overcome it with excellent results.
Sense of community over single stars
One powerful thing we have is the sense of unity, and when high-difficult times arise, it is incredible to feel the support from your teammates. With a strong sense of community within the team, challenges can be easier to digest.
I remember one time at a former job, we faced the biggest product challenge so far in my career: we were running against time to build an entire digital entertainment ecosystem for LATAM and US Hispanics at the same time, but even with such pressure on us (the product team), we were able to deliver as expected despite long night work shifts and weekend sessions. After several months of massive effort, all that remained was the feeling of having achieved an excellent product with the best people on your side.
People are the number one risk factor in whether a product thrives or fails. Even with all the available methodologies or frameworks, if a person isn’t good, they will still be a poor resource. Conversely, a talented person, even without methods or technology, will find a way to make things happen in the best possible way.
Over-complex technology or processes
The second risk factor for failing to create a tech product is adopting technology or processes that teammates don’t fully dominate or even understand. Trends in technology are part of everyday life, but that doesn’t mean your company has to adopt every new method, tool, role, or technology that emerges. As I said before, context (company and talent) matters; technology, roles, or processes should be according to the people who will handle them. Bringing sophisticated dynamics to a non-senior team will only create frustration, confusion, and delays to your projects.
People often underestimate the power of basics; I’ve seen many fantastic products built with a straightforward approach, and they’re so simple that people can master them quickly. One of the beauty outcomes of starting from simple product creation approaches is that, after learning the technique, it comes to innovation, and from there, I’m sure creating a product will be a joyful process of discovery.
Sometimes we think adopting whatever new thing on the market makes us look edgy, more efficient, or sophisticated, but after 20 years of experience, I have to say it’s not always the case.
How to help surface these problems?
From senior positions or high leadership levels, understanding what your company or team needs and what it is capable of is the most crucial insight when creating new work dynamics. Based on the information you can extract from your company or teams, ideate a sequence of steps where people feel comfortable enough to start developing things without the fear of not knowing what they are doing, what tool to use, or what role is essential to take into account in a specific stage.
Quick tip: in these discoveries, the UX team can be king, because that’s actually what we do: understand how people behave in front of technology, roles, or dynamics, right? If you want to make a difference in your company and move beyond the designer stereotype of “only drawing beautiful things,” this exercise will elevate your strategic thinking and impact on the company. I’ve done this in every company I’ve been part of, and so far, it has made a difference in perceptions with other teams and stakeholders.
AI as a thinker rather than a tool
With AI in the mix of product development, not taking this technology with some caution is a high risk of failing to build a technology product. We all know that AI allows us to ship products twice as fast as before, but to me, it is also a double-edged sword that can cut you if you don’t know how to use it properly.
AI, as a technology, is like a wormhole that lets you get to the other side in seconds, but treating it as the sole protagonist of the story might be a mistake. The majority of the results AI gives you when you prompt something are based on global-scale context; sometimes that’s enough for your needs, but sometimes, if the AI lacks the proper context, it is highly probable to provide a vague answer.
A common mistake with AI solutions is misunderstanding the new product dynamic: the possibility of starting from “the solution” towards users, rather than the other way around, as we were used to. When this scenario is treated as an absolute (design, product, and development), we can overlook small things that could make our product flawed.
How to help surface these problems?
It is good to adopt AI as a new core technology for your team, company, and even your culture, but so far, use it as a lever for your progress and don’t start leaving human expertise behind. There is still a lot of hysteria about whether AI will replace us, and following market trends in layoffs without any fundamental basis only increases the fear among tech professionals. My advice on this issue is not to discourage people from saying the AI is all mighty (it will be in time, and we’ll lose the war against it), but right now, what we know is really valuable. My prediction with AI (I can be wrong) is that people will appreciate human nuances and imperfections in all creations rather than AI’s fake perfection.
With all these years of experience in the design field, I now look at things differently, and not every new tool impresses me as it did when I was a kid seeking knowledge and experience. I’m still learning for sure, don’t get me wrong, but with all this technological evolution in almost 20 years, I’m more into getting to basics to solve things and guess what, it always works; we humans are complex and that’s the beauty of UX, we understand humans (the good and bad things) and as I write this article, I realize this is a deep human reflection of how we sometimes, make something more complicated that it should be when the solution sometimes is right there in front of us.
To write this article, I want to credit all the fantastic information sources and other authors who wrote about related topics, all from another exciting perspective.
Product Management vs Project Management: Understanding the Skill Requirements
Don’t follow the AI trap: stop and think
Not every feature Needs AI: A Practical Guide on Gen-AI in Product Design
AI Won’t Kill Live Performance. It Might Save It.
Building technology products is easy, but we made it complicated was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.