Path to 10x growth. A Lighthouse story.

A small growth team, including a temporary CTO from Paralect joined Lighthouse. They spent 6 weeks working closely with the Lighthouse and in a short period of time improved team communication, introduced engineering leadership, improved technology, implemented a Webflow-based landing site, weekly releases, QA process, product roadmap planning and many other smaller things.

Outside expertise and the right advice were able to change the trajectory of the company. We joined in mid-May and in June the North Star grew by 17%. The ultimate goal is 10x North Star growth to raise Series A funding. In this article, we outline the most important changes we made to the team, processes and product to set Lighthouse growth path.

Lighthouse helps people rent a place to live and also pays a cashback reward. They hire realtors (internally they call them Lightkeepers) to streamline the user experience of moving. They optimise the renting process and return some of the money paid to realtors back to the users. Paralect immediately saw the value the company brings to people and was pleased to join their journey.

It all started from the discovery phase, where we spend time diving into the product, technologies and processes. Matt, co-founder at Lighthouse, flew to Lisbon to work closely with the Paralect team for 4 weeks. He spent endless hours explaining every little detail of the current product development process, company objectives and many more.

Matt is an outstanding founder who passionately believes Lighthouse can change the way we rent flats forever. During the first week of working together, we identified critical areas where help was needed:

The initial discovery was not enough to understand the most important changes. In fact, we spent 6 weeks identifying and iterating on some of the decisions. But it was enough to find areas to get started and investigate deeper.

Open communication is a key element of any healthy company. People should share their thoughts, provide feedback and communicate freely. 90% of their communication should happen in public spaces. As founders, we should remove blockers and encourage this.

Lighthouse had three separate engineering teams who rarely communicated with each other. Engineers were trying to resolve some of their issues by talking to managers instead of talking directly to other engineers. That was making their communication slow and inefficient. We helped to improve that by making a few key changes:

It takes time for everyone to get know each other, but within a month team communication became efficient and much more independent. The sign of this is the amount of questions and issues you, as a founder, need to resolve.

Assign a product manager and an engineer responsible for developing and releasing features to production. Personal responsibility magically triggers inner mechanisms which help get things done. Individual team members know someone is waiting for a feature and don't want to let them down. We see this approach work well for many of our teams. On the other side, some of our clients get into the trap of the ‘shared responsibility, where there is no single responsible person and it takes 2x+ to get things done.

From week 2 on Lighthouse we defined Dev Owners and Product Owners for every feature we were working on. A Dev Owner is the person responsible for delivering a feature to production. It’s not done until the feature or fix is in the user’s hands.

A Product Owner is the person responsible for the feature quality from the product standpoint. Together, they form a small team to work independently and make sure each feature or fix gets to production.

This change is essential for any team that wants to move fast. For every new feature, you just need to define a team of engineer & product manager who can work independently to release it. They’ll reach out to whoever they need and resolve all blockers on their own.

Knowing the company plan is very important to keep the team motivated and aligned. If the plan is fuzzy and defined in day-to-day activities, the company performance will be slow. Your team may work hard, but not in the direction you need. Some of the best founders we worked with always have a clear product roadmap and make sure the whole team knows it.

Shortly after joining Lighthouse, we found out that no one on the team actually had a clear picture of the master plan or even the plan for next month. Different team members worked on different parts of the product but were not aligned on the overall company plan. This is a very dangerous situation — teams without a common goal often pull the company in the wrong direction.

So on day three of working together, we sat down together with the founding team and wrote out the 8 most important features to work on. Prior to that, we met with product managers, remote teams and their leaders. They didn’t know the whole picture and this was leading to disconnects between different parts of the application. We implemented the following plan:

Here is the plan we’ve created:

Release dates are critical to any product plan:

Every feature should have a release date. This date is set by the Product Owner and Dev Owner, so the rest of the team knows when something will be done. Release dates help make changes more incremental and release them more often. They force both engineers and product managers to accept trade-offs, cut less important things and release changes to production.

For the first few weeks, we failed to assign deadlines to a few features and didn’t release them all on time. But later — as we made process adjustments — the whole process started to work. During the month of June, we implemented a lot of features and missed 2 deadlines out of 8 by just one week. On the retrospective, we discussed why we missed deadlines and found out we didn’t account for a few technical things in the first place. We added one tech debt item to our backlog.

LinkedIn releases to production 3 times a week. This is a great pace, but it also requires a lot of processes and good test coverage to achieve. For fast-changing companies with small test coverage, we believe weekly releases with a predefined QA process are the best. Weekly releases are still fast, but also give you some time to properly test things in between releases.

We recommend teams strictly define the release date (ex: on Wednesday, at 6 am CDT). Teams should publish changes on every release and postpone the release if any issues are found. Pushing a release back for a few days is usually not a good idea — it will distract a good part of your team from their current focus.

When we joined Lighthouse, releases were a bit chaotic. Engineers would go and deploy a feature to production when it’s ready. This sounds like an ideal approach, but in fact, it was leading to reduced quality of the product. A lot of time went into spending time on deploying and hot fixing bugs on production. In order to fix it, we introduced the following changes:

North star or a few key KPIs are a great indicator for you and your team that everything you do commits to the company's success. We recommend that founders publish this metric so everyone is aware of it.

At Lighthouse, we defined the number of placements (rentals) as the North Star metric. This metric reflects customer value (customers are happy when the flat is rented) and Lighthouse gets paid when a flat is rented. It also measures company growth as the company has to hire & improve the process for realtors.

We set 300 (a 10x growth in placements) as our target plan for the next 12 months. That happened in the pizzeria name Lupita at Lisbon. We felt this number is a bit optimistic at first, but when we started to brainstorm how to achieve it — we found there is a way. This number helped greatly unite the team. For the big features and initiatives, we always ask if this change will help to improve the North Star.

If you already found your product market fit or believe so, the next destination is growth.

The users of Lighthouse love the product, as it’s much better compared to the normal moving experience. Renters have a dedicated realtor working for them (we call them Lightkeepers) and also receive a cashback reward after renting, which is really great deal.

We identified very few changes needed to start growth experiments:

We believe that simplicity is a key to success because a simple app is easier to change and maintain. So we are always simplifying technology to improve the delivery speed and chances of success.

Historically, Lighthouse collected a lot of technical debt and complexity. We made a lot of changes that simplify the overall solution and allow the team to move faster in many directions:

As a founder, you should remember that the quality of the code and the size of the technical debt will affect your future delivery speed. You should give your engineering team some time to address technical debt and keep improving code quality all the time.

At Lighthouse we created a space to track all technical debt items. We also dedicate around 20% of the sprint capacity to resolve technical debt tasks. Aside from delivery speed, it also keeps the engineering team happy and excited about things they do. This increases their motivation.

Before these changes, we often saw the engineering team spontaneously working on the engineering tasks and missing feature deadlines. Tech debt planning helps prevent this.

As a founder, you should be always nice. Some of the best founders we know treated everyone on the team the same. It does not matter if you work with a remote outsourcing team or in-house — you want to keep their motivation high. This will affect both quality and speed of your product.

The Lighthouse founders certainly deserve 10 of 10 in being nice category. The changes we made paired with their natural ability to be kind, respectful and helpful to everyone on the team made a huge difference. Different team members became more proactive and now contribute much more to the company's success.

This is Paralect<>Lighthouse team brainstorming about the growth plan and drinking wine in Lupita pizzeria at Lisbon.