What’s it like to work for a tech startup and be involved in the planning of a project right from the start? I’ll tell you more in this post.
One of the times I learned the most was when I was hired to coordinate a business intelligence project for a startup that offered business intelligence as part of its product.
Planning
Here is the deal: I learned that it’s not about this setting things up for now. It’s about leaving the right gaps that would make the product differentiate from the other products, but filling the gaps that could make that product an MVP. Just like tug-of-war.
The MVP
On the one hand, there’s the client, who is negotiating with their own customers and stakeholders which functionalities will go into the MVP. On the other is you, who must understand Business Intelligence as something that needs to grow in functionality, usability and information.
The problem is that when you’re hired, you do exactly what your client asks, right? Well, not always. The client hires you so that you not only do what they ask, but also tell them when something they ask for isn’t feasible.
Those who have been working on projects for some time already know how this process works, but for you who are just starting out, it may be important information to know. The client is hiring you as an expert in something so that you can take a stand on it.
The flexibility
But it’s also important to know that things don’t have to be so tough. These clashes of ideas can be conceded by one side. The product will never turn out the way it was designed.
And certain factors can determine when someone will give in, such as deadlines, budgets, contracts that have already been signed and team changes.
Of course, something that has to be made clear to the client is what they are losing when the business intelligence team gives away the initial planning.
The team
In the companies I’ve worked for that had projects like that, the team is generally small, usually made up of one person for each function, sometimes one person performing more than one function, such as ETL and data visualization.
It’s also possible to have a business person and a product owner, depending on the type of project.
I have to make a small observation here: generally, startups are gateways for people who want to get started in business intelligence (at least in my reality). So don’t expect a team full of experts. It can happen, but it’s not often the case.
Execution
In this type of project, the start of the project usually takes place at the same time as the maintenance, as there is less time for planning (compared to a “normal” project). This means more adjustments in a shorter time.
Yes, it can seem like a nightmare for developers who will have to exercise the ability to reconcile the new demands of the product owner with the improvement adjustments that may be necessary.
However, there is a positive point here: gaining agility and knowing how to negotiate demands.
Validation and testing
Validation and testing take place directly but correctly. Given that the team is small, the product owner would like to see more functions present in the product and the developer queue is full, the testing stage has a difficult job.
And it’s important that this stage isn’t forgotten, because the more bugs that appear, the more the developer will be swamped with work, and it becomes a vicious circle.
Maintenance
Maintenance usually consists of a lot of bug fixes and performance improvements. Very similar to execution, maintenance appears to correct the short planning time of the product. In other words, the product was planned and grown with the idea of including the most basic functionalities that would deliver the greatest number of benefits. This usually means that development is not the most performant.
I remember many times having to force the entry of improvement corrections as an activity for the team because the product owner didn’t see the value in it. However, several times, customers with a lot of data complained about the dashboard being slow.
For this reason, it is important to have an active maintenance process, where the team is attentive to correcting bugs and improving performance.
Conclusion
Planning is short, the team is small and execution is often challenging.
Although it’s stressful, working on projects like this challenges us to be more efficient, more performative and to communicate better. In my case, these were periods of great professional growth. It’s like 1 year turns into 1.5 or 2 years of growth.
Leave a Reply