When we started working on our products, especially our software, we had a pretty inexperienced team. Some of us had already worked on software projects at other companies or participated in research projects at universities or research institutions. The team’s most experienced member, in terms of years of professional experience, was a software engineer with three years of experience.

The two of us founders had about a year and a half of professional experience before we started the company. When we started developing software, we only had more senior team members in sales and marketing. Some of them had 10 or more years of relevant professional experience.

This situation had its pros and cons. The good news is that we had a clean slate. We didn’t have any preferences when it came to tech stack because our team members had years of experience in this field, and we weren’t worried about AI coding tools, which we had seen in other, more established companies. But there was a big drawback. None of us on the product side had ever been involved in the whole life cycle of a product, from first ideas to successful launch and, if necessary, even getting rid of a product. So, the team really had no idea how to build the product.

None of the engineers really had a clear idea of what needed to be considered in terms of software architecture, database design, and other best practices, such as website translation. I took on the design at the beginning as one of the co-founders because I had taken over the product area from the two of us. It was only about nine months after we started working on it that someone from the team took over the area completely. So, designs that weren’t exactly top-notch were put into place right from the start. There was also some uncertainty in product management. For example, we didn’t do problem-oriented customer interviews at the beginning. Instead, we showed designs and asked for feedback. This meant that as product manager, I often translated customer requests straight into features instead of digging deeper to understand the real problem. There was a similar pattern with suggestions and requests from the sales team. The salespeople were picking up points without us asking them tough questions, and before we knew it, we had built our feature factory.

How we fell into the trap

The situation described above sounds pretty bleak and chaotic. But really, everyone was excited that the many Excel templates and services we had built for our customers were finally going to be taken to the next level: our own software. Everyone knew the team was pretty new and that a lot of best practices still had to be developed. We also realized that adding customer requests to the software wasn’t getting the results we wanted, and that my designs weren’t up to par. Everyone on the team really put their all into it, and they were all really fired up. This sorting phase took about half a year. During this time, we released our first MVP. There were also some lively discussions within the team about how exactly we could become more professional. We came up with two internal measures to professionalize the team:

1. We actively sought coaching in product management, design, and engineering.

2. We started using Scrum as a framework for the team.

The idea of starting a coaching program came up at the same time in the sales team, as my co-founder wanted to run one there. The team decided it would be good to have someone from outside give us feedback and share best practices. The coaching itself started about a year after we started developing the software, and it was a great fit. Over the next year and a half, we saw a lot of professional growth in all areas. The leaps were huge, especially in product management and UX/UI design. I’d suggest that any early-stage startup think about coaching services, especially if the team is rather junior.

We had sort of introduced Scrum at the beginning, mainly in the customer success area, to have a basic framework for processing customer orders using dailies and a Kanban board. But the way it was carried out was more like Waterfall or Zombie Scrum. Since Scrum was already familiar in the company and the idea of additional coaching came up later, we spent a lot of energy on introducing Scrum as a framework. The idea was that if we just copied the process of successful companies, we would automatically build a successful product. A lot of us learned about Scrum in software engineering classes in college or in our first jobs. The engineers really pushed for strict acceptance criteria and the ability to work on one thing in a focused manner within a fixed period of time. The product and design teams did some preliminary work to figure out what needed to be implemented. Disagreements quickly arose here, too. The reviews often left customers and other stakeholders feeling unsatisfied. Also, the salespeople were worried that there would be fewer deals if we showed how the project was going. There were also repeated incidents that, in theory, should have been avoided by using the Scrum framework. For example, the sprint goals and the work packages they contained had to be followed up on a large scale each time. We talked about the goal with the product owner during sprint planning, but the engineers usually made the specific adjustments to the packages on their own as part of their day-to-day work. So, the goals weren’t always met, and a big backlog of stories piled up. These stories had to be dealt with eventually to keep the product from falling apart. A lot of people felt like everyone was really busy, but not much was getting done. The engineers also shifted their focus from solving specific customer problems to working on sub-areas of features and technical refinements that should be implemented. The coaching later addressed these points.

What to do with Scrum

First, it’s important to note that there are definitely good uses for Scrum. My experience has shown that when working with a junior team, where there’s some uncertainty around best practices, it’s best not to be too focused on the processes outlined in a framework like Scrum or similar.

We tried a more product-centric approach, where product, design, and engineering got regular feedback from customer success and customers. The interviews with customers, where they showed what our software can do and what problems it’s actually supposed to solve, were particularly eye-opening for everyone involved. The 1:1 sessions were also a big step forward. A lot of the team members were more willing to make suggestions for improvement or raise other issues in this format than in formats prescribed by Scrum, such as the Sprint Retrospective. We also put more emphasis on our OKRs to set longer-term goals so that individual developers don’t get stuck in a rabbit hole during sprints.