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:

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:

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:

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:

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.

To conclude

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.