Among these diverse experiences, one particular project continues to stand out even years later.

The Spotify Opportunity: A Catalyst for Innovation

One of my clients was on the brink of taking their website and product to a new level, capturing an opportunity to collaborate with Spotify. 

This venture necessitated a demonstration of the concept for the planned features, focusing on enhancing their machine learning algorithms and displaying precise voice-to-text synchronization. 

With only four months until their meeting with Spotify and hundreds of thousands of synchronizations needed to be done, the pressure was on.

With a tight deadline, we were stricken with hurdles to overcome even before the project started.

Disagreements over the payment model between leadership and the client threatened to derail the project. The client preferred a pay-per-piece model, whereas our company favored a pay-per-hour approach, aiming for at least a 50% gross margin. 

Yet, by combining negotiation skills and mathematical problem-solving, guided by my “everything is solvable” mindset, I managed to offer a solution that met the needs of all parties involved.

After solving the payment problem, the CEO at the time directed me to draft the project contract, trusting my comprehensive understanding of the workflow, objectives, costs, and client.

The contract was signed shortly afterward, and we were good to go!
The next challenge Involved onboarding and training roughly 250 people within a four-week period, aiming to accomplish hundreds of thousands of synchronizations before the deadline.

The client demanded nothing less than perfection, with a 100% quality requirement for the synchronization work. This wasn’t just about impressing Spotify; the client’s vast user base, accustomed to actively providing feedback, left no room for error.
This task underscored the importance of efficiency and automation, as manual processes would have been unfeasible.

As I delved into the MVP tool, it became clear that its current capabilities fell short of what was necessary to meet our project goals and timelines. 

This realization marked yet another hurdle, challenging us to enhance functionality under tight deadlines.

Of which I believed would be the most difficult…

Oh boy, was I wrong…

Surprising Development and Rapid Progress

This list arranged the functionalities in order of priority and detailed strategies for evaluating the effectiveness of these suggested features, providing a structured plan for both development and assessment.

Additionally, the list featured a dashboard designed to encompass all the necessary metrics for monitoring and assessing the project’s progress for both sides. Additionally saving time on reporting. 

I didn’t have my hopes high…

Unexpectedly, the client’s development team swiftly implemented a list of enhancement options provided, releasing new features within 48 hours. 

As the features were rolled out and the team commenced syncing work, the more time spent on a project, the clearer the improvements that could be made. With 250 individuals contributing to the project, it only took two days before an influx of additional feature requests was sent.

After additional prioritization by the client’s product department, the development team worked their magic, rolling out new features within 24 to 48 hours. Our team’s accuracy soared to 99.5%. 

This turnaround time will be kept till the end of the project.

This rapid turnaround was a departure from my previous experiences, where developer adaptation tended to be slower.

And I liked it… Oh, it still has an effect to this day…

Seeing the release of the features and functionalities, it was time for a new challenge…

Embracing the client’s request for daily progress, one of the objectives I set for myself was to change from daily to weekly and eventually to Monthly call. This goal was met with a simple reply, “Let’s see,” by the Client. 

We managed to shift to monthly calls by the second month. It wouldn’t be possible without the team’s hard work and the development team’s responsiveness to feature requests.

The developers comprehensively grasped the requests and were keen to work wonders in ensuring the project’s success. Ultimately, two companies from entirely different industries, collaborating across multiple departments, achieved some of the most remarkable synergy between the product team and users (both internal and external) that I had witnessed up to that point.

Even though Spotify chose a different route, the project’s results, exemplary team collaboration, and outstanding performance laid the groundwork for the client to continue working with us for another seven years

Soon after this project, I assumed the position of Scrum Master for an internal product at the company I was with at the time, with the objective of translating user needs to the development team.

Transition to Scrum Master: A Contrast in Collaboration

However, the contrast in team dynamics and receptiveness to feedback was a heaven-and-earth difference. 

Regardless of the feedback or feature requests submitted or the metrics and examples presented to evaluate the success of those functionalities, the product team showed no openness to them.

Amidst the development team, only a single person was open to considering and implementing feedback. However, this individual, along with myself, faced an uphill struggle, repeatedly overshadowed by the broader team’s resistance, effectively fighting a losing battle.



He left soon afterwards…

Internally, the teams faced even greater challenges since they had no options, and leadership demanded to use of the tool. Shortly after implementation, overall productivity plummeted dramatically, with staff becoming increasingly overburdened from working extra hours to compensate for the tool’s inefficiencies. This led to rapidly growing frustration comparable to being caught in a torrential downpour. 

The term “Crap” became synonymous with the product during discussions. When executives recognized that the product’s objectives were unattainable, some form of improvement seemed inevitable. However, rather than starting afresh and building from the ground up, the decision was made to continue patching the existing codebase, further complicating matters.

Yet, the development team maintained the belief that users’ feedback should not be trusted, assuming they were avoiding the tool for trivial reasons. 

This perspective was far from reality; all of our operations prior to this were intensely manual, tedious, and dull. Introducing automation would significantly ease everyone’s workload and enable the company to handle more business without having to allocate more staff to projects.

Now, the shocker…



The developers not only disregarded feedback from internal users of the tool but also ignored the needs of paying customers, leading to an adoption rate among the client base of less than 10%.

Being part of the “Internal” team, in my roles as both the Scrum Master for the product and a Project Manager delivering results to clients, I found the development team’s communication style and attitude concerning.

It would have been one thing if our feature requests were based merely on bias or feelings, but we accompanied each request with a method for quantitatively assessing its success.

Despite adjusting communication strategies and tactics across multiple areas without seeing improvements, I realized it was time for a change.

During this period, I successfully increased our Gross Margin from 40% to 75% while also doubling the efficiency and volume of our deliveries.

Meanwhile, I continued to expand my knowledge in product development, agile methodologies, and product management behind the scenes.

Approximately a year later, with no clients utilizing the system and a decrease in delivery volume due to limited resources and investments, the entire product was ultimately discontinued and abandoned. 

In the process, significant time and resources were wasted.

After the team underwent changes with a new VP of Product and a new CEO stepping in, the company started performing significantly better and had a new product. However, I chose to depart just before these new products took place.

The fundamental features of their product, in its current iteration, can be traced back to the initial feedback provided by us and the internal teams.

Reflecting on the Journey

Our efforts extended beyond mere delivery. With a skilled team of business analysts and UI/UX designers, we completed several hundred app designs. We crafted over a thousand product requirement documents for apps that are yet to be developed.

All of that experience only reinforced a vital insight I gained during my time with the sync app: products designed with the user in mind are more likely to succeed than those that aren’t.

Our organization has adopted this philosophy wholeheartedly. We prioritize user-centric approaches in product development, recognizing that the most valuable brainstorming comes from our users themselves—whether they are customers utilizing our systems or internal teams leveraging AI and automation to boost productivity.



While openly developing our B2B Data product, we apply the same principle to a stealth app currently under construction. Through interviews with over 1,000 users, we aim to gain insights on how to leverage the features to efficiently address their specific needs.

So…
If you’re considering developing an app…



Remember the importance of continuously listening to your users. 



They are not just your customers; they are an integral part of your product team!