What NOT to do to (re)build your product

5 lessons that we’ve learned while rebuilding our product.

I remember as if it was today the commotion that was involving the technology team while they were discussing about the idea that our android jedi had: to create a platform that would allow us to integrate our point-of-sale system with several ERPs and any other partners who wished to.

But before I start to talk about this, we need to go back in the company’s history so you can understand our context.

When PDVend was born, the team was composed by two founding partners e none of them were developer. We didn’t have much cash and there was a certain urgency to develop the first MVP. In the occasion, the partners decided to outsource the development and consequently the entire technological stack was defined by the hired company.

Shortly after it was impossible to run away of the necessity to internalize the development team. So, PDVend was established as a technology company and started to hire the first software engineers.

The absence of well-structured technical decisions in the beginning of the company made us quickly had a large and monolithic legacy, without backend and frontend separation and full of “palliative solutions”. Imagine how easy it was to maintain this structure.

Slowly we made some effort to improve the structure we had: we separated backend and frontend, we invested in technology and doubled the team in 3 months. However, we were still far from the goals we had.

And by the way, one of our biggest interests always were to stablish partnerships with other companies. We wanted to let our customers free to use other systems that solve specific problems without worrying about managing information between the point-of-sales and the other systems.

For this it would be necessary to build integrations and with the structure we had it was very hard to do that. We didn’t have a public API neither a mature enough API to make public. We also didn’t want to bring the integrations effort to our side because we'd already had bad experiences with it in the past.

Until one of the PDVend’s partner (and android jedi) had the brilliant idea: WHAT IF we build an integrations platform? Something that would work magically and allow our users to simply make a “plug-and-play” between our POS and other tools they wanted to.

The idea seemed to be very promising: “nobody is doing this”, “we will innovate the retail market”.

Quickly everyone in the team were excited to start developing the new solution. So we made our first big mistake…

#1 Lesson: the importance of the validation.

The most important step before to start to build any product is to validate the idea and the business model, to study the market, among other important business analysis. We completely ignored it. We start from an assumption and begin to develop at full steam.

Already in the first meeting with one of the possible partners our excitement was completely massacred: the business model we had designed did not make any sense to them.

The next meetings with the others interested in the project were slowly reaffirming what the first had already made clear: we would have to change the business model and adapt the application and the new APIs to these changes.

The result? With the changes we would have to make, the initial idea would no longer make sense. We, however, didn’t want to waste all the development hours that already had been spent on the project.

Our choice was to give up the idea of the integration platform and use everything that had been developed to recreate our server and application.

After this disappointment, we had to settle for the choice we made. There were still good points: it was our opportunity to rebuild our server and release a well-structured public API.

We were able to choose the new technology stack in a much more conscious way and it was still possible to reduce infrastructure costs. Everything seemed to be returning to normalcy. Until we learn our second lesson in the worst possible way.

#2 Lesson: ALWAYS start with an MVP.

When you begin to develop a new product, you are not sure how your product will be accepted in the market, or whether the solutions developed by the team really solve the users’ problems.

You need to validate the product as soon as possible. For this, you don’t include everything you would like your product to have. You develop only the minimum necessary to solve the initial problem of the users you have decided to reach.

Oh, but we were not creating a new product. Why bother with this detail?

Well, we find out later that it doesn’t matter if you are going to create a new product or if you are rebuilding one. You need to build an MVP.

Not having defined very well the MVP of the new solution cost us exactly nine months of development until our baby was born. The problem was this delivery didn’t contemplate all the features that our users already used.

Under these circumstances, we could not migrate all the customers who already used our solution to the new structure because we didn’t offer the least feasible for them!

This small slip made us have to keep two structures totally separate, offering maintenance in the old, while we tried to evolve the new. We could only migrate a few clients until all the “basic” features were ready.

Believe me: to explain to users that the functionality they needed was already available in the new version of the application but they were not allowed to use that application yet is not a very easy thing to do…

#3 Lesson: plan, plan, plan!

Unsurprisingly, a well-done planning can be powerful to optimize team work and avoid rework, as well as to improve communication between stakeholders and development team. I wonder, then, why do we have so much difficulty in doing good planning and especially in following it?

In our case, the answer was simple: whenever a new business opportunity that seemed very promising appeared, we wanted to stop everything we were doing and start developing what was needed to meet this new opportunity.

Since there was planning and we were not following it, eventually we just stopped planning.

See, when I say we stopped planning it means we were not doing any planning at all. Neither sprints, nor roadmaps or anything. Absolutely nothing.

Okay, you must be wondering “how did you survive like this?”. Actually, I don’t know either but it was disastrous and explains why it took so long to deliver the new application's first version and why we’re still migrating our customers to the new structure.

Of course it didn't last long because it was unfeasible to keep a development team running this way but it took enough time to create a mess in product development and make us understand that we needed to change it as soon as possible.

So the good news is: we’re planning well now and most important we’re following it because we have learned our lesson! Eventually I’ll write about how we plan and how this improved our work.

#4 Lesson: DO NOT hire an unexperienced P.O. if you are in a hurry.

Ok. This is probably going to be a big shoot in my own foot but I have to talk about it.

When I was hired, I had no experience as a product owner. Actually, I didn't even know what P.O. meant.

My background was quality assurance, so I was used to point enhancements and always tried to capture the users' vision, but that means nothing when you become the person who's going to make decisions about the product. It is much more easier to say "oh, I think this could be improved in that way" when the decision is not yours and you don't have to explain that to anybody.

Other problem: I had never worked with agile methodologies, specially SCRUM. In other words, I knew nothing and would need to study hard to start thinking about being a product owner.

It took me several months to understand what were my responsibilities, how I should prioritize the product demands, why the SCRUM ceremonies where important, among other common practices that are REALLY important and we were not doing at that point. But I got it.

When I finally was understanding all these things, my second battle just started: I had the job and some knowledge but still needed to get respect as product owner. My team didn't trust me at that time and believe me, this is really bad.

But I won. Gradually I began to empower myself and gain the confidence of the team. We started to run tests and improve processes, I got closer to customers and my decisions have become better grounded.

I'm still studying a lot because I understand that everyday we have new lessons to learn (I also want to talk about lessons learned eventually). But at this point I feel much more ready to lead a product than I was in the beginning. And we finally find our breakeven.

#5 Lesson: the team makes the results.

Creating synergy within a team is not an easy task. Finding the right people for the job is even more difficult. But if you want to have a high-performance team it is essential to find this breakeven.

For a while, we had problems with these two points. We’ve never had a lot of turnover on the development team, however, we had a pretty serious problem of misalignment among development teams.

The communication wasn't good, the teams were not aligned on what and when they should develop, and even when we were planning well, we were not able to meet the deadlines.

The worst: these problems didn't only happen inside the development team. It was general, the entire company had these communication troubles. Business and development didn't talk to each other.

Things have only begun to get better when we learned to hire the right people for the job. We started to care more about soft skills, not only technical knowledge, because we wanted to have self-manageable teams. We also made the goals of the company clear to everyone.

To help our devs in this task, we put our CTO to personally lead the backend team. After few weeks, we noticed the evolution: our backend team improved estimates, passed deadlines, and started to deliver 4x as it did before.
Gradually, they also gained confidence to make more technical decisions, without needing to be mentored by the CTO. They have become self-manageable (now we're doing the same in our frontend team).

The sales team started to sell much more, the new business opportunities appear to evolve faster and the communication between the areas got pretty better. In short: every single person in company is working for the common and very known goals.

We're still paying for the mistakes made throughout PDVend’s history, but every mistake taught us an important lesson. If I could summarize all the lessons we've learned over the past few months in just one advice, I would say keep all your team together and closer, make sure everyone knows the company's goals and let them free to participate in product decisions.

It doesn't matter the process you're running on your company or how qualified your team is if they are not engaged in something bigger than just develop some features or don't feel comfortable to make suggestions and disagree with your decisions. Make sure they know what they should do and the importance of it.

Be open to changes and to learn new things everyday. That's the way we found our breakeven.