Five Learnings from the OBI Product Development & Team Lucify

After nearly a year with Team Lucify at OBI, having learned about the history of the product and the Team, I have collected 5 learnings that I believe can answer this question and explain the ongoing success of the product. The product, which started six years ago, centers around a tool that supports OBI employees in coordinating projects between private customers and craftsmen. Having grown over the years, the team now consists of 2 product owners, 6 back-end developers, 4 front-end developers (from denkwerk), and one UX/UI designer (me, also from denkwerk!). Many of the team members have also been working on the product from the start.

1. Giving People Space instead of a Plan

Especially in the early stages, it might be impossible to know with clarity what the product actually needs to be. You might craft a detailed plan and give it to a motivated team to be executed. Then, as unexpected questions, problems and new information start to emerge, the team might start to feel frustrated and stressed, as the scope and to-dos keep moving around in front of them.

At the beginning of the product’s development, Team Lucify didn’t receive a detailed plan. There were requirements and goals, but the Team had the space to explore possible directions together. Being able to influence the shape of the product fostered a sense of ownership that increased the involvement of the various experts in the Team. Such sentiment was a valuable motivator towards quality that remained among the team members even as the product evolved over the years.

2. A Shared Focus – Beyond Defined Roles

Creating a good product requires coordination between many levels of expertise, and collaboration is an unavoidable necessity. However, a willingness to collaborate might not be enough. For a certain time, the team’s designer was pushed by the design department to pursue big, innovative concepts. Meanwhile, the developers needed small concepts to keep iterating on the product’s setup. This mismatch created friction in the needed collaboration.

As a new designer from denkwerk joined the team, she was able to better align the scope of design concepts with the current needs. Being aligned on the same focus meant that, while everyone has the autonomy to pursue their own expertise, they remain motivated to try to bring all the necessary perspectives together as soon and as frequently as needed. At the end, the best results happen when everyone can look at the question “How do we make this work?” while being aligned with the scope of the answer.

3. People Make a Team - But a Team Makes its Processes

When a group of people come together to work towards a common goal, certain collaboration patterns will naturally emerge. It is then easy to just keep repeating them without questioning whether they could be better or feeling empowered to change them. In the first years of Lucify, the team was encouraged to hold frequent Retros, which allowed them to find their own processes and ensured that everyone had a chance to speak and be listened.

Over the years, the team kept self-organizing such retros, embracing the mindset of reflecting on what works and keeping only what makes sense. As new people join the team, it is impossible for them not to feel and embrace the team’s history of openness and trust. A core resilience remains in the team’s communication: if something doesn’t work, we talk and try something else.

4. Feedback Cycles, Feedback Cycles everywhere

The meta-communication and a flexibility around internal processes created a similar mindset when tackling external communication. A peculiarity of B2B context is that users volunteer feedback about the product, especially when something is not working as expected. Leveraging the chance of a continuous dialogue beyond immediate problems can bring deep insights into workflows and the opportunity to test possible solutions early on.

Similarly, as the business keeps growing, new features will be required. Figuring out the exact requirements can be a bit of chicken-egg problem, when what is needed is better understood when things are being used, but for the things to be in use, what is needed must first be identified. The way through this can be in the decision of implementing first a part of the process, or something that covers most use cases, and then remaining open to adjusting the direction based on how things roll out.

5. Accountability is a gift – To the Product and Each other's

When working on a new feature, there are multiple opportunities in the team for feedback and iterations. While there are rounds of design, code, and PO review when a feature is ready, weekly exchanges on work-in-progress solutions, for instance between Design and Front-End, give the people’s involved the possibility to easily share roadblocks, frustrations, or feasibility questions. These frequent exchanges not only help finding a good solution quicker, but also allow the different area of expertise to blurry hand-offs lines and learn from each other.

Receiving reviews and feedback isn't always easy, especially when one is not used to. However, embracing it transforms it from mere critique into a valuable source of growth. Not only in one’s own expertise, but also in developing an understanding on how the others work. Though it takes time, the result is not just higher quality releases but also personal development and commitment to the product for the people involved.

Final Points

Many of the things mentioned might need extra time upfront but bring much bigger value along the way in the long term. The time saved at first might end up being used later to rework and fix problems, while the overall care and involvement fostered by them is likely to create something more permanent. At the end, Quality cannot be prescribed, but people have the ability to create the spaces and processes they need to keep moving towards it. L