Building a SaaS Flight Operation Management System | FlightOffice
Background | Our Founder The Helicopter Pilot
As a helicopter pilot with over 25 years of experience in the aviation industry, our founder saw a big problem in aviation and wanted to fix it. Many aviation companies were still running their multi-million dollars business on carbon-copy papers and Excel spreadsheet, so he conceptualized a new end-to-end flight operation management system, FlightOffice.
FlightOffice helps companies in general aviation (GA) market to manage every aspect of their operation, things like scheduling flights, rostering crew, planning flights, collecting flight data, monitoring flight and duty time, tracking currency records, billing, etc.
90% of the world’s aircraft fleet falls within the GA market, and the remaining are the airlines fleet. A few examples of GA companies are corporate flight departments, private flight charter, aerial support, medevac support, and companies battling wildfires.
Market Research & Product Persona
I met with the founder to understand the product vision, who would be the customer for the new product, and the inspirations behind.
We carried out extensive market research. To build our product personas and roadmap, we tried to address the few key questions below:
- What are the characteristics help us divide the market into different segments?
- What are the market size and potential annual revenues for each segment? For us, aircraft fleet represents the market size.
- Which market segments have fewer requirements?
- Who are the main competitors? What features do they offer?
Questions 1–3 are important to define our product personas. The answer to question 4 would help us understand who we go against, and how should we position ourselves.
For the MVP, we wanted to serve market segments that have fewer requirements; but would lead us to the more lucrative customers.
We segmented the market based on regions and operation types. In aviation industry, each region governed by different Civil Aviation Authority, so some regulatory requirements vary between countries. Also, complex operation types usually requires more sophisticated features.
To build the product personas, we met with two potential customers fit within the selected segments. We wanted to learn their pain points and motivations to use a system like FlightOffice.
Based on the results from the market research and personas, we built the initial roadmap. We identified two frequently used “modules” as part of our MVP offering. We grouped features in modules, and each module represents a function in flight operation management. For example, the flight scheduling module provides features to manage flight booking.
Subsequently, we built the product canvas for each module. The product canvas defined the goals, the features, and the metrics to measure success. For this exercise, you can use the product canvas tool in romanpichler.com.
The market research was an ongoing process as the industry landscape changes over the period. Also, we revised the personas and product roadmap when we discovered new information about the market and customers.
UX & UI Design
I took part in the project when we were still making decisions on platform architecture. One decision was to choose the UI framework for the platform.
I helped the team put all the options on the paper and researched UI components offered by each framework. With the designs in mind, I laid out potential use cases for each UI component.
The decision was critical, picking the right framework could help us speed up the development. In fact, it saved us a lot of time from reinventing the wheel.
It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice. — Steve Krug, Don’t Make Me Think
A quote from one of the most important books in UX design, and it was the first book that opened my world to the UX.
Navigation and workflow play an important role in web usability. Even though we only had a few features in the MVP offering, but to decide on the layout and navigation we did the designs with full-bloom product in mind. This may not apply to a grown product with established design guidelines. For us, it was an important step to make sure we had the designs right from the start. As people said throwing away codes is more expensive than throwing away designs. Also, the full designs allowed us to explore design possibility in different use cases and scenario.
Before settled on the final design, we ran through a dozen iterations to explore different layout, navigation, and appearance.
After that, I prepared a design guidelines document. The document outlines our personas, product philosophy, design principles, and design elements. The guidelines played an important role in communicating design thinking behind. Also, it helped the team set up the CSS master stylesheet.
It was my first project, and I skipped the wireframe. However, the design process should always start with wireframe. It is the same reason as you don’t code before you design. The wireframe is the most efficient way to explore ideas for content, layout, and navigation. It also keeps the team focus just on that, not on the appearance.
Interactive Design Prototype & Usability Testing
Next step, we linked everything together in UXPin to create a fully interactive design prototype.
There are a few reasons we built the interactive prototype:
- To get a feel on how everything looks like when it comes together.
- To communicate the design and specs with the team. It’s a more effective approach as the team could navigate around to visualize the workflow.
- It allows us to run usability testing before any coding.
We built a comprehensive prototype to mimic the actual system. For instance, each item in the list linked to a specific page with real-life data. To run the usability testing, we selected a few respondents from the potential customers list.
We ran the tests on the web conference, with screen share. We provided respondents a summary of the product and asked a few background questions. Then, we gave respondents a context and asked them to perform a series of tasks in the prototype. We recorded the process and jotted down notes as it went. In the end, we asked for overall feedback and suggestion.
The results from the tests were very positive, most respondents had no problem navigate around and perform tasks. We made some tweaking to address a few minor issues. Also, the feedback gave us tremendous insights on features priority.
We used ProductBoard to manage and prioritize feature requests. We channeled all feedback from sales and support to the board. It showed the number of requests on each feature, so it helped us decide what to build next.
Product Specification Document
Not every feature need a specification document. For simple features, we jumped straight to the job stories. For complex features, we prepared spec docs to outline all the product specifications. The complex features usually involve a specific domain knowledge or complex mathematical operations.
For each new “module”, we conducted extensive research on the topic before the design process. Below are research techniques I used:
- Interview customers to understand the business requirements. Often, I also asked for sample documents they use in operation.
- Study relevant regulations to identify the requirements.
- Look at how other competitors do it and learn what they do well and what can be improved.
- Join the relevant online forums. I joined a few aviation-related forums; it was a great venue to find things that not addressed in the regulations.
- Browse through the reference library. Over the years, I was building up an aviation reference library. Whenever I found something new, I put it away for future reference.
The spec doc is part of our blueprint to communicate the functionalities. Also, it is an effective thought process to unfold some overlooked details. Though, writing a spec doc can be a challenging process; it requires a nice amount of details. A spec doc should cover:
- Project background — I usually provide brief domain knowledge, business workflow and use case, and problems the features try to solve.
- Job stories — You can use user story, but job story worked better for us as it provides a context that leads to the action. Learn more about job story.
- Functional requirements — Besides laying down the details, I used a lot of visual techniques to communicate complex functionality. Things like flowchart, numerical examples, design screenshot, and demo video. It’s more like a show and tells technique.
- Glossary — If the domain knowledge involves industry jargon, I defined those terms at the end of the document.
Scrum Framework in Development
We used the Scrum framework in our development process, each bi-weekly sprint represents a development cycle. Depends on team structure and product complexity, you might find the weekly sprint or monthly sprint work better for you. We started off with the weekly sprint, but it did not give us enough timeline to measure accomplishments.
Sprint Planning. We started each sprint with sprint planning meeting. It’s a 2-hour process, the objectives were to:
- Set the sprint goals.
- Present the features and address questions.
- Estimate feature complexity and identify potential challenges.
- Prioritize and put cases in the Kanban board.
Spec docs were handed over ahead of time so that everyone got the chance to grasp the general requirements and domain knowledge. After I presented the features, the scrum master would facilitate the planning poker. Planning poker is a fun and effective method to help the team achieves consensus on feature complexity. Often, it also revealed the potential challenges. Then, we broke the features into smaller cases; we put and prioritized it in the Kanban board.
Daily stand-up. For the rest of the sprint, we had the daily stand-up. The team got together for 15 minutes every morning for the status update. Some companies are doing the asynchronous stand-up through chat channel, like Slack. You may find one work better for you than the other. We tried both methods; I find synchronous stand-up is a more effective method for a few reasons:
- A great way to build team relationship and culture
- Ability to identify and address blockers sooner
- A more collaborative and motivational approach
With async stand-up, the truth is not everyone takes their time to check what their peers are up to, especially when we get really focused in a zone. So it’s possible that one goes down the rabbit hole not knowing others have something valuable to share. Async stand-up usually more suitable for a large or distributed teams, with people in different time zones. Though, for it to work every member must commit and take initiative to learn things going-on in the team.
Sprint Retrospective. For us, each sprint ended with a 2-hour sprint retrospective. It was a structured process facilitated by our scrum master. On the first 10 minutes, we wrote comments down based on three categories — (1) things we should start doing, (2) things we should keep doing, and (3) things we should stop doing. Then, the scrum master led the discussions on each comment. At the end, the team voted for the 3 most important items and came up with an action plan.
The goal of retrospective is to build a culture where team constantly learning and improving. So it is important to make sure the team focus on the solutions, provide constructive feedback, and remain respectful to others.
Retrospective doesn’t have to be a boring meeting, there are many ways to make it fun and entertaining. Here are a few ideas for retrospective, check it out. We used Team O’clock, it’s a great tool to facilitate retrospectives.
Testing & Release
We applied continuous integration (CI) and continuous delivery (CD) in our development workflow. That enabled us consistently delivering new features to our customers. Depends on features complexity, each release cycle took average 2 to 4 weeks.
We used Heroku deployment pipeline to manage our QA and releases. The pipeline automatically spooled up a review instance when new PR passed the unit testing and automated code review. Our dedicated QA guy or I performed testing to ensure software quality and the features meet the requirements.
Once the instance passed all the tests and peer code review, we merged it into Staging, and eventually released it to our customers. After release, we performed post-release testing as a final safety measure.
I managed the releases and prepared release notes for the major releases.
Product Adoption Evaluation
As part of the user-central design process, we performed evaluations after each major update to gauge user adoption. Based on the results, we also constantly refined our personas and planned for remedial actions. Following are the evaluation techniques we used:
- Business analytics tool — We integrated Domo with our user data, it showed statistics on feature usage.
- Analyze user data — This is a great way to learn user behavior. For instance, missing data may indicate users did not use a specific section or flow through an expected workflow.
- Customer survey and call.
The results from an evaluation may not always positive. Normally, it gave us a pretty good idea what could have gone wrong. Though, this would require further analysis to plan for remedial actions. Here are a few situations I dealt with:
Users are not aware of the feature. Users did not spot the feature in the product, and the release notes might have slipped through their mailbox. In this situation, we tried to answer the following questions:
- Does the feature prominent? — Sometimes, a feature might be prominent in the product, but users did not navigate to that section.
- If the feature is not prominent, does the feature relevant to most users?
- If the feature applies to most users, is it a frequently used feature?
We ran user engagement campaign in Intercom. We designed a series of automated messages to introduce these “hidden” features. It triggered messages based on the number of web sessions or specific page users visited.
Some features were meant for advanced users, so we put these features out of sight or at less notable places. It would crowd the user interface if we displayed every features.
But if we found most users using the feature frequently, then we made the feature more prominent. If the feature only applies to some users but frequently used, we considered allowing users configure whether to show or hide it from the interface.
Users know the feature, but not using it. This is not necessarily a bad sign. Some features are not for everyone. However, if the adoption rate is much lower than expected, then it’s possible that the feature doesn’t serve the personas, or the personas don’t reflect most of the customers. If that’s the case, we refined the personas to make sure future releases provide most values to our customers.
For complex B2B products, it usually more challenging to drive adoption within the existing users. Often, it requires a formal process to coordinate users and integrate the new features as part of their organizational workflow. For us, we sometimes offered training programs to larger customers.
Users used the feature, but stop using it. Every user or customer is slightly different, there is no one feature work for everybody. For example, we released the flight scheduling module, a few of our customers stopped using it because their flights were mostly ad hoc and no fixed schedule. That situation was okay.
However, if many of the users stopped using a feature, it certainly a bad indication. Product planning can only minimize risk, the costly mistakes inevitably slip through the fence sometimes. In this situation, it requires a thorough understanding of why users stopped using it, and what works and what doesn’t work for them. It could be different reasons, such as:
- It doesn’t meet the business requirements.
- It targeted the “wrong” user groups. For instance, billing for an on-demand charter business differs greatly from a company serve long-term wildfire battling contract, so it’s important for us to choose the right user group.
- The efforts of using the feature outweighs the problem it tries to solve.
After a thorough study, you may have to adjust the features and re-evaluate the user adoption again.
The goal of driving adoption is to make a product more adhesive and ultimately keep the churn down. If a user use 90% of the features, then the user will more likely to stick around as it’s harder to replace the product.
Outcome
It was an incredible experience building a flight operation management system from scratch. We released our MVP to the market after a few months. Since, we continued adding new features to the product. We also released FlightOffice mobile app to both App Store and Google Play Store.
In less than a year, we doubled our subscription fee per aircraft with customers spread across the world. From the US, Canada, Europe, Africa, to Australia.
