Product Management Case Study - FileLinx IFS
The FileLinx software is an incredibly powerful no-code modeling software platform in which all sorts of solutions can be modeled by business consultants. In over ten years, the platform evolved from a software application with “just” modelable forms to a full-fledged B2B SaaS platform providing workflow functionality, dashboards and process management features. The new product was to be an evolved version of that platform.
The new product was to be an evolved version of that platform. So a team was assembled to make it happen. We wanted to take this version of the platform even further, so we had to really think it through before coding a single class or interface.
The product team consisted of the CEO of the company, the Sales Executive, as well as a Product Manager and myself as Development Team Lead / UX Expert.
The development team consisted of a Product Manager, 3 senior back-end developers, 3 junior front-end developers and myself.
Why building this product was necessary
The technical reason: The existing FileLinx software is over a decade old, and this reflects in the source code. The software is compensating for browser quirks that aren’t there anymore, it’s not taking advantage of newer technologies and it’s not very well suited to adapt to the multi-tenant excitement that is enterprise PaaS. Besides that, the platform UI wasn’t created with the requirements of today’s end users in mind, and isn’t flexible enough to be molded into being more user-friendly.
So for technical reasons, we decided against gradually modifying the existing product, and instead building a completely new product. We decided to maintain compatibility with the legacy database model, to ensure existing customers could work with the new platform as well.
The business reason: A software product that increased in features over a decade has a tendency to become a Jack Of All Trades. This makes the product harder to sell for a couple of reasons:
- The core problem the product solves can become unclear;
- The product will become less easy to use when the UI accommodates a host of different functions;
- The style of the UI might not match anymore with what users expect. Besides that, there was a specific reason for the business to want to build this product. The existing FileLinx software was as flexible as it was versatile, because it was able to adapt to the client’s data structure and processes. While being incredibly powerful, this was also hard to sell because clients would either: a) not believe this to be true, or b) look for a product that solved their specific needs instead of the generic solution FileLinx proposed.
This new product was to adhere to a more specific use case (more on that later), while allowing the core features of the platform to be available. This would allow sales managers to fit the product marketing more closely to the client needs.
The client’s reason: While clients recognized the power of the FileLinx platform, insights in audit logs were scarce.
The end user’s reason: There was a list of very valid feature requests from end users for the existing platform that would improve the product tremendously, but couldn’t be implemented for technical reasons. For example, a user would want to have multiple pieces of information open at the same time. This would require the implementation of a tab-like UI - or at least something that allowed the user to switch contexts. The existing platform could not facilitate that type of interaction because of technical limitations in its backbone architecture.
How this product came into being
Creating an MVP wasn’t as textbook-structured as I’d like it to be. A couple of things happened around the same time:
- One of the backend developers came up with a prototype for a new kernel that was tremendously faster and capable of multi-threading, allowing processes to be handled much more efficiently.
- Sales & marketing discovered that most of our clients would start using the platform in a very small setup. When satisfied with the initial results they gradually started using more and more of the platform’s features.
- Consultants put in a couple of requests to improve their workflow in the platform significantly - resulting in implementation projects finished quicker and thus more money on the short term.
- A couple of clients wanted to build a custom portal to interact with the platform.
- The product owners found that it would be a viable option to merge all three existing products into one - or at least have them work together closely - because they share similar data.
The butterfly effect
Once we started talking about the above, and started putting two and two together, it influenced things we weren’t expecting. Considering the fact that this would become a core product of the organization, and the time investment required to build it, we had to reassess how we handled priorities for our existing products. We also had to take a look at how we handled technical back-up for our consultants - the people modeling the actual solutions for our clients. We had to evaluate how the organization actually made money. And most of all, we had to think very, very hard on what this new product should be, and what it shouldn’t be.
This took shape in a couple of processes: For one, the management team worked on a company vision and strategy. This helped shape the strategic positioning of the product. Simultaneously, Team Leads of all departments started figuring out better ways to collaborate. Also the FileLinx Product Owner and myself started gathering information from stakeholders (i.e. end users, client management, consultants, sales, support, developers, management) about product usage, needs and wants. We distilled this information to its essentials in a couple of intense multi-day sessions to come up with a product vision and a roadmap proposal, to be discussed with management.
Getting our hands dirty
When the rough outlines of the product were starting to take form, we started building the product. By then, we knew a couple of things:
- Lots of existing functionalities needed to be ported to the new product. Porting everything would mean our development time would triple, if not more. We decided to allow the existing platform and the new product to run in parallel, so we’d be able to reuse major chunks of functionality (like our custom automated workflow engine per client). Just this move already skyrocketed the products business value, since we could deliver the product way sooner.
- We wanted to focus on end users and have them be our primary target audience. While this might sound like a logical choice, this meant we had to deprioritize other audiences like our consultants, even though we knew how much improving their workflow would benefit the entire company.
- The new product would be focused on how most customers start using the platform: as a document management system (DMS). The product would be like a file server, but on steroids: the power of the FileLinx platform (with workflows, monitoring tools, task management, etc.) would be its backbone. We described the product as an Intelligent File Server, or IFS for short.
- To be future-ready, we decided IFS would be built as a SPA, or Single Page Application. This allowed us to build reusable components, thus increasing development time down the road. A SPA would also allow us to optimize for load time, since we’d be able to only load the required scripts & styles.
- We wanted to simultaneously build an API for the IFS, allowing custom portals and extensions to be built for the platform.
My role during development was pretty diverse: I was the UX / Design Lead for the product, the Lead Frontend Developer, and I acted as a co-Product Owner. This all came together pretty naturally: my day-to-day work ended up being a mix between mentoring frontend developers and reviewing their pull requests, technical discussions with backend developers, sprint preparation sessions and estimates, working on interface designs, triage and interface sessions with the Product Manager.
To stay on the right track
As the product team, we had a couple of strategies to ensure we remained on the right track, scope-wise:
- We had progress presentations to get the rest of the company up to speed on what we were building, and to share user feedback. While we worked in two-week sprints, most features took more than one sprint to complete. Also, gathering the entire company for a presentation is quite expensive, so meetings like this were only scheduled when necessary.
- As part of an effort to be more transparent about what happened at the development department, I sent out a weekly newsletter with a status update from the development team. This included a report from the Product Manager on the new product, IFS.
- We ran an alpha / beta program to allow our colleagues to actually try and get work done with IFS. Since the existing FileLinx platform and IFS could run in parallel, users could switch between them to stay productive. In a later phase, we opened the beta program up for a couple of clients, too.
- If things didn’t work out when trying IFS, users could submit a bug report or feature request which the Product Manager and myself would perform triage on, and rewrite as a user story for developers.
- The product team (the CEO, the Sales Executive, the Product Manager and myself) worked together very closely to assert we were all on the same page about product features and scope, to incorporate both user needs and business needs.
- The Product Manager and I would perform user tests and interviews to gather feedback on newly added features, overall navigation and ease of use. This either occurred at our office or via phone / video call. We made sure to communicate the results of those tests with the development team as soon as possible.
During development, we hit a couple of rough patches, and I’d like to share an example: When we started working on IFS, we decided to maintain the navigation flow of the existing FileLinx platform, but with tabs. Users wanted to work on multiple things at once, or might get interrupted while working on one thing and had to switch to another without losing their context.Tabs felt like they could solve these problems. The way we implemented them was to have certain actions (like performing a search) always execute in a new tab.
When users beta tested IFS, one of the requests that often came back was the option to close all open tabs at once. Users wouldn’t manage their tabs, and just leave them open when working on something new, resulting in them feeling lost in the product.
Instead of implementing the “close all tabs” feature, we decided this tab system wasn’t working as intended. We switched to a “history stack”, where each action that resulted in a new tab would add a new entry to the history. The user would by default work in the most recent entry, and was able to switch back to up to 5 history entries. When we user tested this solution, we found a significant increase in how efficient users could switch tasks.
Even though the process of building a product from scratch was intense, it was also immensely gratifying. IFS is available for new clients, and gradually being improved to fit existing clients. If you want to know more about IFS, check out the FileLinx website.