Table of contents
1. The users
2. Their needs
3. Value chain
4. Evolution
5. Factorial’s gameplay
5.1. Becoming an ecosystem
5.2. Jobs to be done
5.3. Efficiency for innovation
⚠️Disclaimer. All the content, assumptions, claims, and so on I do on Factorial Product are my own interpretation, and it doesn’t represent the company’s reality. This post is an open practice on Wardley Mapping to understand how more products are relevant to map.
Factorial is a product/company quite known in Barcelona, Spain, as they have their headquarters here, and they run a quite famous podcast in Spanish, Podcast de Itnig.
They are an all-in-one HR SaaS for SME that intend to automate everything HR, from time management, to talent from hiring to performance review, via finance such as payroll, and employee expenses.
I used it during 2020-2022 when I was Engineering Manager.
What I want to say with this is that their business domain is quite huge and complex. Which makes it a perfect product to explore using Wardley Mapping.
The other reason why I chose Factorial is that we have been experiencing several changes in the tech industry compared with the Zero interest-rate policy, ZIRP for short, period.
We are seeing less rotation, harder to find competing job offers for software engineers, and other roles within the tech industry, a push for efficiency, and that translates pressure for HR software to adapt to the new context where focus moves from attracting and keeping talent, to employee efficiency, followed by policies like Return To Office, RTO for short.
You can see more in the following post about the ZIRP, and the change in the industry.
1. The users
By looking at the top menu items, we can already tell that Factorial is a huge product serving a variety of users and industries. I’m not able to map everything, therefore I’m focusing on the Technology industry needs because that’s the ones I’m more familiar with, plus it’s the purposes of this post.
Based on the menu item by Role, we can assume there are three users to map.
2. Their needs
When I started to understand the user needs, I noticed that I might mapped it wrong. The landing page lists three roles, but I think this is a marketing acquisition decision to attract the main buyer personas that convert the most.
I think their users looks more like this:
I merged CEO and HR managers because their expectations right now much aligned. The landing page says that HR Manager to streamline administrative tasks and focus on team development, and CEO to optimize, reduce structural costs, and boost the business.
Which long story short, it is about efficiency.
I believe that the role of people management and growth (at number of employees, and employees career) isn’t the primary business focus anymore. I’m basing the article with this assumption.
The ultimate value proposition is about to spend less time on manual tasks related to HR and dedicate that time to productive tasks, those that aim to generate revenue. From this perspective, I will map the user needs.
Furthermore, I made explicit the needs of Managers, and Employees. You cannot streamline administrative tasks, nor optimize structural costs without reducing the gross time spend where you have more people, in non-HR roles.
So, I consider factorial is achieving their mission by providing an all-in-one solution targeting HR managers/CEO as buyer personas, and then rolling it out to the product users such as HR managers, Managers like Tech Leads, and Employees.
In order for this to work, they have to delight those three users.
3. Value chain
Factorial’s pricing page is the full representation of the components needed to fulfill those user needs. You can see this within the application after registering, I didn’t find it public.
By looking at the value chain, we can see how much features are related to Talent Management, involving the different users. In order to understand more of that area, we should do another map only zooming into that area, but I leave that for the reader to do. I don't to spoiler all Wardley Maps we could do on Factorial’s business landscape.
4. Evolution
As I was adding the evolution axis, I noticed that almost all the Factorial’s capabilities are in the product or commodity space.
Well known client needs to be integrated in one place.
We can even see some of the commodity products being included in the pricing space and not being optional, while other’s that are more in the product area being an add-on to the monthly basis subscription.
After trying the Factorial’s product thanks to the free trial, I had the impression that several capabilities are self-contained, not depending on other capabilities other than shared concepts such as employee, company, and alike. Everything you need to do on a capability, it is under the same tab/URL.
I’m not sure if they are reusing code, copy-pasting, creating shared libraries, or having subset shared capabilities as a Factorial’s platform focused on common user facing needs. I’m having this guess due to the common UX, that requires a lot of shared building components to be sure that the app behaves the same, combined with the shared language on what some key concepts mean, like employee, company, etc.
5. Factorial’s gameplay
The beginning of the post I assumed I could describe how post-ZIRP affects SaaS HR solutions for SME market such as Factorial.
Even though I cannot share a 1:1 relationship, I think I can describe three main factors that could represent a response to a market that needs to be do the same with less/do more with the same. For both, clients and providers.
Becoming an ecosystem.
Factorial cannot serve an hetergeneous market by itself. So, it invests on becoming an ecosystem where others can build on top of.Rethinking the UX of HR needs with Jobs to be done.
If clients needs to have an even more efficient HR department, and all the related management tasks, they have to stop investing on local feature optimizations, and think the E2E HR user journey, and optimize those jobs to be done.Efficiency for innovation.
For internal development, decrease the cost of solving new critical user needs by creating an Internal Product Platform. Instead of requiring more product-tech teams to keep delivering/removing features, reduce the cost of creating new capabilities by having a compelling and thin product platform for the main use cases.
5.1. Becoming an ecosystem
There’s a moment when you cannot solve a huge variety of user needs, and you need to opt for another approach. Allow external developers to solve those user needs for you in exchange for an ecosystem they can sell their products/integrations to.
I saw it quite clearly in the Integrations page.
The ecosystem gameplay can be expressed quite clearly as a Wardley Map. We have 3 users:
Factorial. Wants to create an ecosystem for others to innovate on top of.
Factorial customers. Want to adapt/customize more Factorial to adapt to their needs.
Factorial partners/developers. Want to publish integrations, to either serve better their customers within the Factorial’s ecosystem, or obtain new users thanks to Factorial’s ecosystem.
This approach, which means releasing an API where others can build on, will support Factorial in the next way. Factorial will be able to add metadata on how the different set of integrations behave, and detect future user needs that they want to invest on.
5.2. Jobs to be done
I recall a Podcast where they were sharing some of these insights, but I’m guessing the reasons, and the approach. Remember, I’m exploring as an external viewer.
As up to today, Factorial’s user needs are quite self-contained. Which means that they solve one thing, like Time tracking. During a podcast, I recall that they want to create a new user experience that go beyond of self-contained features, to Jobs To Be done. Or how I understand it, instead of focusing on needs == capabilities, moving into needs ==> a set of capabilities well interconnected.
My bet here is that Factorial is investing in a better UX, moving from commodity capabilities for well-known user needs, to reinvent how HR is doing their job to make their job even more efficient.
The guess here is that they cannot make the HR processes more efficient within the same capability, and they need to move to make the Job To Be Done more efficient to have huge impact. Moving from local optimizations, to big picture optimizations for their clients.
The approach might be AI Agents.
Factorial partnered with Microsoft Azure OpenAI during early 2024. There is a high chance that this Jobs to be done will be driven by AI agents touching a broad set of capabilities.
5.3. Efficiency for innovation. Platform?
I recall a Podcast where they were sharing some of these insights, but I’m guessing the reasons, and the approach. Remember, I’m exploring as an external viewer.
LinkedIn says there are 1.666 associated members, which I can assume between 300 and 400 works in product-technology.
Sales, ops, business development, and customer-success are around 800.
Factorial focuses on SMEs, but the amount of people in sales, ops, and customer-success suggests that:
They are approaching an upper market, maybe more mid-market.
The platform isn’t as self-served as I expected, and it might require a high touch engagement model. That’s due to the emphasis on customer success service.
Combining the point 5.1. becoming an ecosystem, adding new capabilities, and addressing new and existing user-needs shouldn’t require duplicating the engineering team. The size is already significant, and the benefit of creating new teams isn’t lineal to ROI.
The amount of customers, and the product size should allow Factorial to have enough data to invest in safe bets, and have great Go-To-Markets to deploy new products to existing customers that those needs have been already detected.
So, instead of creating new full features by new teams, it can be interesting to create a kind of Internal Product Platform, using the Team Topologies Term of Thin Platform As a Service.
The Internal Product Platform (IPP) should act as a set of common capabilities to help product teams to deliver products to address known user needs, or explore new ones.
IPPs enables you to:
Make the product more stable, as you make high-used, high-dependency, use cases stable.
Create a shared language among all teams on key concepts, and the cost of integrating those concepts instead of build-it becomes worth in the mid, long term.
I recall last time I did an IPP to make some sensible decisions such as:
IPP team members were part of product teams, and understood the user problems.
IPP team members had the right product skills such as explore user needs, talk to customers, pragmatic, soft skills, and familiar with Team Topologies to be sure they were creating the thinnest viable platform, and not a big one.
Facilitating the adoption of the platform by use case as soon as they were available, reducing the risk of platform adoption, and be sure we were building the right thing that solves business, user, and product-engineering needs.
A good way to understand the teams context, and where to start investing is to understand the socio-technical system from a team cogntive load perspective following the Team Topologies guidance.
We are building Teamperature to help organizations to make conscious decisions taking into account teams cognitive load, and track the impact overtime. Check it out!
That’s it! I hope you enjoyed the post as I did writting it. Love to hear your feedback, and know which product you want me to Wardley Map next, leave a comment.
If you are from Factorial, and you want to help me to fix some things that are wrong, and collaborate on making a more accurate article, feel free to reach me via DM, at LinkedIn, or at hello at aleixmorgadas.dev. Love to chat! 🙌
I’m helping organizations to design and execute their engineering strategy. If do you think I can help you, let’s chat!
