The way products are being consumed has evolved. Namely, they need to be accessible anywhere, across any device — especially when it comes to work.
Email communication pioneer Front predicted and invested in this shift early on, building out their mobile engineering team early in the company’s life.
We sat down with Pierre Laurac, iOS Mobile Developer at Front to discuss Front’s history, how managing their roadmap has evolved, and how they were able invest in the shift from desktop to mobile applications early on.
Aaron Upright: To start us off, can you share some of the history and the mission behind Front?
Pierre Laurac: Initially our vision was to help people be happier at work. We set out doing that by creating an inbox that helped people work more productively, together.
While that broader vision remains the same, we’ve expanded our mission. We aim to empower people to do their best work by unlocking a world where technology works for people, not the other way around. We’re bringing everything people need to do their best into their inboxes.
Aaron: Why do you think the company chose to initiate those investments sooner than later?
Pierre: Before joining Front, there was already a mobile friendly version of the platform. Once I joined the team, it was decided to build a hybrid mobile app as this had become a resounding request from our customers (especially to get push notifications). So we built a simple Cordova wrapper over our application which was a fairly quick win for us and the customers, while we could dedicate full resources to build a first version of our native mobile client.
Aaron: Getting into Front’s roadmap a bit more, how did the team manage the roadmap when you came on and how has that evolved to how the team manages the roadmap now?
Pierre: Our co-founders (Mathilde Collin and Laurent Perrin) had a similar vision when it came to the features and updates we wanted to bring to the product to push it forward. We kept our roadmap public, completely transparent to our customers. But we would also let them request and upvote some features, and we did use this a lot to decide what to build next.
When it came to working on each project we were small enough that we could all be our own project managers to push projects along the pipeline into deployment. It wasn’t until the team started growing that we decided to bring in a product manager. As her first undertaking, she emailed our customers directly to ask them what they wanted to see from the product.
Aaron: Were there challenges that came from having the roadmap public?
Pierre: Not really! The sentiment from our customers about our public roadmap has always been positive, especially when we were a smaller company. Enabling our customers to see that the product is constantly improving is exciting.
Once the team grew and the product matured, so did the feedback and requests from customers. We realized that we had to be more careful about including bigger feature changes to the roadmap as we knew that once the projects got more complex, it would be harder to change how our product works, without introducing breaking changes in our customers’ workflow. We made sure that we were taking the time to understand the impact of each request and how it would affect the product in the bigger picture.
Our roadmap is still public today, and we still use it to gather feature requests and feedback. We use the requests in the roadmap to help prioritize which projects we work on next, and we set objectives and key results (OKRs) against each one.
Aaron: That’s an interesting approach. Our team uses OKRs as well. Would you say that using an OKR approach has helped to address issues the team faced around scaling?
Pierre: OKRs are relatively new for the mobile team. As the company started to scale, it became more challenging to remember which goals we had set and if we actually had reached them over the course of a quarter. I found that for engineering in particular, OKRs were harder to define since it was hard to measure—do we define success as the level of technical accuracy, level of customer adoption, or something else?
For example, in the first quarter of this year one of the objectives for the mobile team was around reducing the amount of crashes per user. Having those goals in place helped put urgency on the issue for the team. OKRs were great for that aspect of things—keeping us consistently in line and working towards a specific goal every quarter.
Aaron: As a related question, I’m curious to know since Front is such a customer-centric product, how does the team balance between high level product changes and more technical debt pieces like reducing crashes and fixing bugs?
Pierre: We’ve had to iterate on this a few times, and we still do! We tried to have an engineer on-call for the week who was responsible to help our technical customer support person fix bugs. The problem with this method, though, was that we couldn’t always guarantee the engineer on call could handle every bug—some bugs were outside their specialty.
Aaron: What did you end up doing to address this?
Pierre: A friend of mine was telling me how their team was handling bugs. To create continuous momentum towards fixing bugs, which has always been seen as something that isn’t “super cool” for developers, they dedicated one day per week for the team to focus solely on closing out bug tickets. Having heard how effective it was, we decided to bring that approach over to our own engineering team. Every Friday the team reviews bugs that have come in from customers over the past week. The bugs we deem as high priority (depending on severity and impact) are added to the roadmap for the following week. Smaller bugs with low impact are scheduled later in the month. I think once everyone was getting involved and seeing traction on closing bugs—a large amount during a given week—it kept people motivated to want to get involved in fixing bugs.
Aaron: You’d mentioned previously in the interview that Front has a team of technical customer support people. When we first met, I remember that you were leading the technical support team in addition to being involved with the mobile team. Is that still the case?
Pierre: There was a point when everyone at Front was helping to handle support. As we began to scale, it got to a point where some issues were too technical for just anyone to jump in and help out. What we realized was that the engineering team still needed to ship code, we still needed to fix bugs, but we also still needed to reply to customers quickly as well. This has a cost: while you’re working on technical customer support, this is time you are not using to code and ship features, to keep your momentum. So we decided to hire our first technical support person at Front, who was responsible for handling the more challenging questions, and help us debug issues further. This was a key hire.
Aaron: Is there a specific process the team uses to ship code?
Pierre: Before we ship anything, we have tests running on our CI server to make sure we didn’t break another functionality. We create new tests for what we are adding and review the code written by our peers. We also assess the impact of each new piece of code before shipping. “Will the new code impact existing code, how could it affect customers, how difficult would it be roll back if necessary?”
We also try to ship bigger changes by breaking it down in smaller bits, and often protect new code with feature flags, which allow us to progressively roll out and test more sensitive changes.
Aaron: Has the team run into any technical challenges as the Front continues to grow?
Pierre: As the team grows, we have to dedicate more time to planning ahead. Our infrastructure is more complex than on day one and we handle more data, so making changes can take longer to prepare for. As you cannot stop growth, our CTO is constantly on the lookout for these issues and is doing a great job.
Aaron: So, there might be a few readers going over this interview who might be coming from smaller companies with aspirations to grow into a larger company with the same level of transparency Front has into what they are building. What advice would you give to those readers who will need to balance between customer expectations and scaling product?
Pierre: I think where Front has been successful is building something simple first, a first version of the feature, to support what we envisioned for the product. Don’t try to over-engineer the product or its features because it is quite likely that you may never launch that same full version of the product. Also, gather feedback as quickly as you can and iterate just as quickly. Finally, every product decision you make will be something to support in the future, and this might slow down your momentum down the line.