I initially wrote this article in Brazilian Portuguese for UX Collective, and it was published in October 2018. So this text is a full translation of my ideas at that time.
In a regular meeting, the Product Manager comments to the designer that it would be perfect if they had (at the company) a product to execute the function "XYZ." It would be even better if it was built using the tech stack "A+B+C" to develop it.
The designer is excited about the opportunity. He grabs the idea, goes straight to his desk, and starts building the first prototype without asking many questions. After looking for similar products on the market and doing a brief validation with users, he finds considerable evidence to invalidate the Product Manager's initial hypothesis.
"Yeah ... it seems like people don't need a product that does the "XYZ" function. When they want to, they even use the "XYZ "system to do this for free. - thought the Designer.
While the designer was immersed in prototyping without sharing to anyone his initial findings, a Development Consulting Firm was being hired.
The cost of working alone
At the blink of an eye, the product's idea and the prototype arrived at the board of directors' ears. Everyone was excited about the new revenue possibility. A release date was already being defined.
When the designer decided to take off his headphones, get up from his chair, and finally present his research data, it was too late.
"Well...now, there is no more time to change. We will finish the project and evaluate the result, and if the product does not sell, we can stop selling. It is just an MVP." - said the Product Manager.
Thus, the project continued. The designer presented his research to the team with some improvement points in the prototype's usability -which quickly became an MVP with a launch date- and provided general suggestions for the product strategy.
After a low profile launch, they performed several digital marketing actions trying to increase the user base. Some of these actions were based on the research's findings initially delivered by the designer.
Months later, as expected, the product did not sell very well. It had no responsible team for maintenance and had few active users. The most obvious happened: the product was discontinued as quickly as it was launched on the market. And all the money invested on it went straight down the drain.
This sounds quite familiar
I imagine that when you read this story, you recognize yourself or know someone who has been through similar situations.
A random person assumes without any factual data that a new product or functionality should be built. Someone else (e.g., designer) starts building it because it was requested. A weird product is born from this process, costing a lot of money and probably being used by almost nobody.
In general, the details of these stories (and bad decisions) are not visible even internally. Success cases and some small process errors are shared, but nobody or almost nobody shares that they spent a lot of company money, building something useless.
From my perspective, the concept of making mistakes quickly and learning fast has been significantly distorted in most organizations that starts to work with the "Agile Mindset."
Take practical actions, daily
Maybe you have never noticed, but your existence as a designer, especially within a product team, already makes you co-responsible for the financial health of the product you work with.
A significant part of the product valuable deliveries will pass through your desk, it will count on your ideas, and rely heavily on your expertise. Strategically, you should take advantage of this and learn more about the company business, meet people and stop being seen as just a screen maker. It is necessary to change or at least adapt yourself. If you have a more hands-on, proactive profile, similar to the designer of the story I told, take advantage of this reading to think about how to use this characteristic better and not contribute to perpetuating a culture of "doing without thinking."
"In an effort to move fast, companies sometimes trade rigor for speed. They focus on coming up with as many solutions to the problem as possible, without truly understanding the problem." said Chris Fosdick, Partner, The Cambridge Group
Also, remember that not always isolating yourself at your desk with your headphones on, is the best option to build something cool that people will really want to use. Design just for designers is a Dribbble thing, right?
I confess that I have already done this a lot. Nowadays, I recognize that it was a selfish behavior that added very little to the process of building any product. We can always build things on our own, but certainly, adding other people help us build something much more valuable.
In a similar context to the presented story, avoid holding your research findings way too long and try to be organized when presenting them. This helps people to understand that, the research process is also part of the job.
Be prepared to receive a new demand at any time, but also be prepared to ask the right questions when new demand arrives. If you don't know what questions to ask, start with the basics and ask why as often as necessary.
I suppose you want to grow your career as a designer, be more recognized in your job, and participate more actively in important decisions. So, you may need to rethink some things, starting from your own behaviors.