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.
What is Lighthouse?
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.
Identifying weak areas in the company
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:
- Product roadmap planning
- Disconnects between teams and lack of leadership, integrating applications together
- Complex technology leading to an increasing number of bugs and slow delivery
- Quality of the user-facing parts of the application: search and property view. Reduce bugs and improve property data quality
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.
1. Improve communication
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:
- Make communication more transparent. We encouraged teams to ask questions publicly instead of using direct messages. Publishing things to the public is scary, but as you start doing this it becomes easier and easier. The huge benefit of this is that others know the context of your discussion and can join in anytime.
- Introduced #product-leadership Slack channel for lead product managers, project managers, designers and engineers to align the leadership team first and discuss important changes. We used this channel to post upcoming changes, discuss and align the team before they were actually made.
- Introduced #engineering Slack channel and invited everyone there, so engineers have a chance to collaborate, ask questions, discuss tech debt, and plan long term. Fast forward to the future, it took 4 weeks and letting one person go to make sure the whole engineering team start publishing their questions, opinions, feedback and talking to each other.
- One standup for all three teams. The team is located all over the world, but we found a time to meet. Team members started to see each other and talk to each other every day.
- Introduced written daily updates, so everyone, before starting his day publishes notes on yesterday's progress, plan for today and any blockers (so we can resolve them quickly). This helps everyone to stay in sync with everything that’s happening.
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.
2. Introduce Dev Owners and Product Owners
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.
3. Improve product roadmap planning
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:
- The leadership team meets once a month to review progress and discuss the high-level roadmap for the next month. This roadmap, as well as results, of the last month are presented to the team.
- Product Managers work closely with individual Dev Owners to understand an estimate and to support them while features are being developed. A simple product plan makes it easy for everyone to understand everything that’s going on in the company.
- In retrospectives, the team reflects on missed deadlines and how to avoid them. Usually, that results in adding tech debt items into the backlog or reworking some areas to improve delivery in the long term.
Here is the plan we’ve created:
4. Set the release date for every feature
Release dates are critical to any product plan:
- you need to know when a certain feature will be done, so you can plan dependent features
- engineering, design, QA, and product teams need to know when the feature is expected to be released and plan accordingly
- it forces you to accept trade-offs, reduce scopes and focus on getting things done
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.
5. Release weekly with a predefined QA process
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:
- Reduced number of releases to one per week every Wednesday at 9 am UTC. Since the team is pretty small, we rotate the person who deploys changes every week.
- Introduced QA process to the team. Every feature is now being properly tested before going to production.
- Introduced feature toggles, which allow us to turn off a feature on production if we feel it’s not ready yet.
- The engineering team knows that every change we deploy should be production ready or hidden behind a feature toggle.
6. Define The North Star metric or a few key KPI’s
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.
7. Make product changes that help you to grow
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:
- Replace the custom landing site and blog with a Webflow site. This enables the marketing and product team to quickly edit copy, add new pages and optimise conversions without waiting for developers.
- Finish up the custom CRM system. The system is used to streamline and optimise realtor operations, so we can scale the number of placements processed by one Lightkeeper.
- Streamline the end-user experience. As a user I’d love to see all communications with Lightkeeper in one place: status of my building inquiry request, list of recommended buildings, etc
8. Simplify technology
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:
- Added Feature Flags — a process that allows turning on or off features without writing code. We believe that everything that takes more than two days to build should use a feature flag for a few reasons: a) to share and receive early feedback b) to make smaller and less risky changes c) to deploy to production any time.
- Implemented monorepo (hello turborepo) and merged all repositories into one. That reduces time spent switching between repositories, allows pull requests with cross-project changes, and simplifies dependency management.
- Implemented a resource-based approach to writing API and Frontend. The idea of this change is to keep things that belong together as close as possible. Here is a great overview of what a resource is.
- Used Webflow to design and launch the landing site and blog. The custom-built landing site took a lot of time to change by engineers and now the design and marketing teams can change it on their own.
- Used Retool to implement common admin and support tasks. For example, we can turn on Feature Flag for individual users on production using Retool.
9. Plan technical debt
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.
10. Be nice!
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.
