GO BACK
Chasing unicorns is a damn expensive hobby. Every year, startups eat up billions so that only one out of tens or hundreds can profit in millions. Founders and product owners raise money from investors and sacrifice their independence to conquer the market faster. Ultimately, however, they don’t raise enough funds most of the time. Maybe it was right to say “shut up and take your money” at the right moment?
Cash Rules Everything Around Me. Even the most turquoise organizations cannot deny it. The development of project management methods, processes tweaking and optimization or employee motivation is basically triggered by the universal need for money. Design agility involves certain risks.
We all want to be lean and agile so that the result of our activities, measured in numbers, is as high as possible. Even if we focus most of our energy on reducing losses, in the end, we take into account the profit that has increased thanks to the generated savings.
These savings fall into the same pocket with the remaining factors and remain available only to the most curious ones. In this way, we lose focus and unintentionally omit a lot of valuable data and ultimately intelligence.
Learning from your own mistakes is an especially useful (though expensive) skill, but the organizational culture and the diplomacy embedded in this ability do not always help. We often hide the negative impact of finances with “smokescreen” words. When an investor yells “I lost my money!”, the manager communicates it to the team by saying “we should be more effective” and we all look by default for new solutions and improvements – instead of looking back, we are constantly looking for ways to move forward.
Meanwhile, losses are often the key to drawing the right conclusions. If we go over the certain flow steps in the process without proper consideration, the next solutions will most likely be infected with the same errors.
Example:
A small team of senior JS developers does not provide functionality within the expected time. The investor, wanting to accelerate the development, orders to hire a new programmer. Introducing a new person to the project will distract the team, which slows down project progress even further.
If the investor would better understand the reasons behind the team’s ineffectiveness, he would conclude that it only uses its potential in 60-70%. Better equipment and a few working days devoted to work automation would solve the problem.
Unfortunately, now he has to pay for another developer who will work on the same equipment and his efficiency will also be at 60-70%.
Solution A:
From now the project costs $20,200 / month
Total spending in 12 months: 12 * 20,200 + 10,000 = $252,400
Solution B:
From now the project costs: $30,000 / month
Total spending in 12 months: 12 * 30,000 = $360,000
Two developers working at 100% do roughly the same as three developers working at 60-70%. The investor will pay over $ 100,000 more for the same processing capacity per year due to a faulty design decision!
Agility in the process does not necessarily mean striving for 100% test coverage or breaking the performance record. While these metrics provide an overview of the technical condition of the project, they are so insignificant from the end customer’s perspective that bringing them to an ideal state in a truly Agile process does not have to be achieved as they do not bring real market value.
Developing perfect technical solutions requires a lot of team commitment and much more extensive communication. As a result, patches work slower and the project becomes heavy due to over-development.
Agile development is all about delivering a working code with minimal effort. Code testing is undoubtedly a good practice and the tests say a lot about the operation of the code, but they should not be done just for the sake of doing them and bragging about it – the optimal technical quality of solutions lies somewhere between the minimum determined by the dev team and the maximum that is limited by the budget.
Ultimately, perfection gets you nowhere. Interestingly, even the issue of security is subject to this rule – theoretically, any system can be hacked. However, the aforementioned development minimum must be correspondingly higher and relevant for the weight, scale and cost of potential consequences of code mishaps. Often, instead of writing the login module from scratch, which is always burdened with a high risk of error and introducing security vulnerabilities, it is better to use, for example, the “Sign in with Google” button, the proper implementation of which is relatively fast and safe.
As long as the goal is a short time-to-market, exceedingly ambitious assumptions prove counter-productive. In a seemingly perfect process, over-enthusiasm can be a waste of resources.
User-centered design is cool. Human-centered cooperation is more important. When the team communicates on the same wavelength, it can spontaneously reduce further potential losses.
A UX designer who is up to date with frontend technologies will not propose a solution at the MVP phase that will consume unreasonable time at the implementation stage.
A frontend developer who knows usability heuristics will be able to adjust the interface to a given screen resolution without involving the UX designer – quick fix, preview, accept.
Working on an application requires synchronization of activities of people with completely different competency profiles. You need to know the distribution of skills in your team to effectively deliver value to your customers.
Good team performance understood in this way is exceedingly difficult to achieve, especially in the era of remote work. Companies that have been “remote-friendly” for years have a significant advantage in this field over those that have been forced to tune the organization during the lockdown and are just now learning about new methods and forms of communication.
In the context of the growing communication needs, tools such as Whimsical, Miro, Mural, Figma and Balsamiq record an impressive increase in popularity.
Certainly, the lockdown and the need to work remotely have played their part in this explosion of users. I believe the selection of the tool should match individual preferences, but let’s take a look at Miro:
Popularization of such tools naturally drives the increase in popularity of the methodologies themselves. Someone who bought Miro to work on personas gets access to dozens of other templates that may prove to be of interest and positively affect the team’s daily work.
You should always equip yourself with tools that will streamline the flow of information in the project. Openness to new tools and methods is also one of the foundations of effective product development.
Experienced designers of both the interface and the software architecture usually notice several potential solutions that should be verified at the beginning of the cooperation and efficiently look for appropriate inspirations or even ready-made solutions on the market. A good example is the Material UI framework, which is usually a safe bet at the prototype stage.
Sometimes, it is enough to review a few implementations on Behance or Dribble and use the inspiration to develop a mood board and then pass it to the developer. This person will use it to put together a clickable prototype that can be presented to early adopters to collect feedback. This organic strive for an effective process in design-minded and committed people is natural.
If you want to deliver digital products efficiently, you need to let people do their jobs. You know what value/service you want to provide to your customers – that’s enough. A competent and well-managed project team will know best how to deliver this value/service as quickly as possible with necessary cost-effectiveness.
Show your trust, share the responsibility and open up to a true two-way communication so that your product will be better and the burden of making it all by oneself will be off your shoulders which often proves to be a draining ride for founders and entrepreneurs! At The Codest, we translate this principle not only into projects, but also into internal processes – that’s probably why we enjoy high retention rates for both customers and employees (true story, both> 90%).
Treat yourself with a bit of laziness, boldly transfer responsibility and let go of any redundant work that is not necessary to move forward – functionalities that would be “nice to have” can always wait.
The process of creating a digital product is a constant collision of different perspectives, experiences and sources of information – each such collision carries the risk of making the wrong design decision.
Good internal communication reduces this risk, but it is only one side of the coin. The question of how to stay in touch with the market remains yet to be answered.
Business Intelligence, Customer Support, UX research departments and many others – just like the development team, they should strive for the minimum necessary to provide specific answers to questions asked by the product owner or the UX team.
The branding itself and the brand communication strategy are also important. They serve to build a qualitative relationship with customers, which then translates into their commitment. If you want to ask questions to clients, you should make sure that they are willing to answer these questions. The tone of your voice matters.
It is certain that being in constant contact with the market allows you to define the right trajectories for the project to make it fly. Less obvious is the fact that the need for this contact should be considered at the very beginning of the project, around anticipating the right competencies in the team (to ask the right questions and answer them) and building a product strategy that will involve the target groups.
Considering all of the above-mentioned issues, we can observe several problems that regularly appear in the design process:
– being overly profit-oriented and avoiding looking at failures,
– inaccuracy and not X-raying own mistakes,
– chasing a perfect product that you have in your head, but which is not what the market needs,
– overzealous implementation of textbook processes – over-development and over-design,
– inflexibility of teamwork and forcing employees to remain only in their areas of specialization,
– ineffective communication,
– tendency to reinvent the wheel.
Process optimization on a macro scale includes the sum of savings. To properly face the above-mentioned challenges, you need to involve your colleagues so that they openly present ideas for improving the process.
Sometimes it is enough to talk less and listen more carefully to subordinates, clients, partners – according to each one’s role and responsibility – to achieve success.
When you are not quite enough, you are most likely overinvesting. Do you have too much money?
Read more:
CTO challenges – scale-up and growth of software products
Which DB to choose for your specific data type in your software project
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch